4 ms·
That stuff is handled at the application level a data store should just be there to store and retrieve data, I think databases used to need to do a lot more tha
by Kequc 12y ago
That stuff is handled at the application level a data store should just be there to store and retrieve data, I think databases used to need to do a lot more than they do now. I thought Postgres required one to include a module in order to gain array support.
Looking into it again now it seems I was confusing Arrays for Hashes, with regard to the hStore extension.
The application is in charge of what data goes into the database. It is performing sanitisation, validation, returning errors, all of that before persisting data. I don't want to have to deal with errors from the database nor do I want to have to manage data integrity from two separate locations.
I want to be able to tell the database to store something and it stores it modern development frameworks can handle data integrity stuff.
- AlterEgo20 12y ago"modern development frameworks can handle data integrity stuff". Wrong. They cant. If you have 2+ applications working with the same db, there will be problems with data integrity that no "modern development framework" can solve.
- Kequc 12y agoIf you have two applications making use of the same database, then build a shared ORM layer and have the applications interact with that. Modern applications do not interact with the database directly there is an ORM. Separate that out and share it between however many applications you want you should be able to swap out data stores not be confined to them.
- sanderjd 12y agoYour solutions to these problems (like "do validation and integrity in the application layer" and "build a shared ORM layer for multiple applications") are definitely possible solutions to the problems, but you state them as if they are obviously the best solutions. They actually sound a lot harder to me and seem to be driven by some theoretical purity in having a dumb data store that I don't really understand. Building a shared ORM layer for multiple applications to use is just a hack around having a shared data store layer doing validation and integrity, which is what a smarter database already does. It's reinventing one of the really hard things that databases are already good at. What is the advantage? I've also never made an application that doesn't eventually want to do something that the ORM I'm using doesn't know how to do, at which point it makes a lot more sense to interact directly with the database than to shrug my shoulders and say "I guess I can't do that". Maybe my applications just aren't "modern" enough.