Skip to main content
Post Made Community Wiki
Source Link
Tangurena
  • 13.3k
  • 4
  • 39
  • 66

There are 3 legacy systems that are close to your requirements:

  1. Pick,
  2. MUMPS,
  3. Microsoft Access

Pick and MUMPS were developed years before the first academic paper on relational databases (which was about a decade before the first commercial SQL based database system made it to the market - from a company we now call Oracle; IBM's first attempt at a product fizzled and a successful SQL based system was later). You might find them still in use (our local public transport system used Pick until recently for the trip planning system). You want nothing to do with either Pick or MUMPS, and the best advice I can give is "step away from the keyboard with your hands in the air!" If you do have anything to do with them, the phrase "you'll be sorry" should be ringing in your ears.

Microsoft Access gets severely mocked and criticized in IT circles as it is quite easy for a non-developer to make a critical business app out of Access and have it mutate into something that the company quite literally cannot live without. It is also quite likely that quite a few developers got their start in developing via MS Access and as things kept getting bogged down they learned how to fix them (the first step is traditionally learning visual basic and rewriting the Access app first in VB, then in something "better"). It is possible to make a well behaved Access app that runs distributed with a huge amount of data - I've seen it done - but there are easier ways to do things, and it takes far less skill to make (and maintain) a well behaved app out of VB and SQL Server.

Since SQL Server 2005, Microsoft has introduced the capability to put CLR into stored procedures and functions. And if you want to be tricky about it, you could make datatypes that you could then use as columns in the database. I think Oracle has had something similar with Java.

That being said, I don't think there is anything stopping you from creating one, or hypothesizing about them. Pick and MUMPS are older than most coders here and reflect a very COBOLy way of looking at the world.

My personal advice is to keep things separate. Use a language that is good at manipulating the data your project needs (with the caveat that sometimes the "best" language is one that you can easily find programmers who can read/write the code). Use a database system that is good at keeping the data your project needs.