4

What are the most obvious drawbacks to this idea for an enterprise(ish) model using the following technologies.

  1. Browser based and native developed GUI using Delphi to connect to

  2. Datasnap server (Delphi, obviously) via Rest which stores documents in

    1. A CouchDB Server

    But gets the structure for those documents from a centralized tree of

  3. JBoss servers connecting to
    1. MySQL databases which have information about all kinds of domain specific things
  4. Which connects to another JBoss server, all the way up to a centralized hosted repository to maintain some sort of control over licensing and structure of the program.

I know that's kind of vague, but bear with me. I'm really asking:

  1. Whether it's sensible to use a mixture of NoSQL and SQL DB's and
  2. Whether it's easier to mix them if they're not connected to the same backend service.
  3. If this is just crazy.

I thought of it on the drive to work and it seems to solve all the problems that we have. I'm not sure that datasnap is robust enough, but we could use node.js or another jboss server instead. I just wanted to go with Delphi since we've got it and know it.

I think this is a fairly normal model, the difference being the web server (or datasnap server) being the thing that has a database attached to it as well as the data server. I think it's better that way, and it would probably make sense if I said this is for medical records primarily and it's better that documents stay separated from things that need to be updated, but it's meant as a general purpose solution for storing info in a structured way.

Peter Turner
  • 6,897
  • 1
  • 33
  • 57
  • So a native Win32 delphi executable as an HTTP Server for remote clients using a web browser? Is that what you mean by "Browser based?", or do you mean "My EXE uses a TWebBrowser to build its UI?" In short, without a diagram and some idea of your goals, I'd say this is unanswerable, and simply a list of technologies, not a design overview. Exactly how JBoss and Delphi have anything to do with each other, I fail to see. Not crazy, nor sane, just vague. A random mix of relational and nosql does seem "only a thing to be done if strictly necessary", and like it could lead to hell. – Warren P Jan 24 '13 at 20:51

1 Answers1

0

You ask 3 questions - and you are talking about medical records being separate:

1: Whether it's sensible to use a mixture of NoSQL and SQL DB's and - My answer is YES

2: Whether it's easier to mix them if they're not connected to the same backed service - My answer is YES, if I have understood what you are asking correctly.

3: If it is crazy - NO, it is not crazy.

4: You later ask if this had been done successfully - and the answer is yes. I have done this already, if I understand what you are doing correctly.

Bingo
  • 1
  • 3
  • I think you understood the question and thanks for the Yes, but do you know if it's ever been done successfully? – Peter Turner Feb 08 '13 at 14:40
  • I extended my answer above - it has been done before – Bingo Feb 09 '13 at 04:27
  • I expect that (contrary to the above) you will have problems in one or more of these areas: performance, data integrity, relational and non-relational impedence mismatches, query construction, report construction, maintenance, backup, operation, stability, and ability to clearly document the gigantic multi-layer design. – Warren P Mar 11 '13 at 13:11