I agree with Simon, but I also twist things up a bit. Databases are just data storage containers, at the most low level, raw definition. A text file could be a "database" for all intents and purposes. There should be things in there to protect the data within, but there also needs to be some kind of filter outside that container to make sure that the data is logical and meaningful. If you were to throw motor oil in a maple syrup bottle may LOOK right... Depending on the weight of the oil, it'd be the same color and texture and all... But.. well... you know..... I'll pass on those waffles.
Simon says (heh) that his applications manage foreign keys, and is flexible, and this is absolutely true. However, what I do is rely on both managing the foreign keys at the business logic level (in my code), and at the database level. I see nothing wrong with throwing a constraint at the database to make sure that I'm not inserting information into the database, parent information already exists. If it doesn't, I screwed something up code wise that would have allowed an unknown entity to place dirty data in my otherwise pristine database. What I DON'T agree with is that EVERYTHING should be thrown at the database. I try to stay away from triggers, for example. If there is something I need to have managed alongside a previous statement I sent to the database, I'll let the code handle it. On Mon, Nov 11, 2013 at 10:27 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 11 Nov 2013, at 2:35pm, dd <durga.d...@gmail.com> wrote: > > > Got it. > > > > Can I conclude this way: Foreign keys works pretty well when > > application deals with parent keys only. But, application may need to > > execute more queries when dealing with child key/tables. > > My feeling is that a lot of this logic needs to be done at the application > level because at that level you have more flexibility and can interact > better with the user. Foreign keys can be useful to enforce > business-logic. But not a substitute for programming which should check > these things first. > > However, that's just my own view. I've seen rational articles written > that argue that every part of business logic possible should be included in > your database schema: constraints, foreign keys, triggers, and all. And > that your app should rely on those doing their jobs rather than having each > app perform its own checks. It's a matter of opinion. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
