This whole thing has gone wildly OT, so I'll check out on this post. On Thu, 15 Sep 2011, Always Learning wrote: > Hopefully that is always possible - retrieving EXACTLY what was stored > in the database. Why would one want the database to manipulate (change) > data ? Is that a solution for lazy programming ? In the ideal world, a database has sufficient internal intelligence to make sure that you don't get impossible data stored. It doesn't mean you can't have wrong data, but you at least keep the database in a sane state. Without this intelligence, your database becomes a bucket of data, where the only controls are in the application. A bug in the application means issues with the validity of the database. > Simplicity and good design makes applications fast. > > If an application is fast and effective, because of its design and > simplicity, why complicate it ? A SQL View is an additional overhead > and not needed, in my opinion, in (my) well-designed systems. But you see database simplicity as being simple, but ignore code simplicity. I don't get why you see them separately. I'm not saying every database you produce should be loaded with every feature you've read about in a book. But a constraint here and there, and a mostly normalised database isn't a bad thing. If you're not joining tables ever, your tables are probably poorly designed, or you're doing database work in your application. There's just a rumbling suspicion throughout this that you don't really need a database. >> I think with most applications like you're describing people have a >> decision to make as to how much logic goes in the DB and how much goes >> in the app. When you're new to it, I think you tend to put all the >> logic in the application. As you progress I think you at the very >> least put in controls into the database to maintain the integrity of >> the data. > > As one becomes more knowledgeable and accustomed to things, one > inevitably regards the database and applications as being integral parts > of the same system. Efficient retrieval of stored data should be a > paramount consideration for the good design of applications. > > Unsure why you mean by "at the very least put in controls into the > database to maintain the integrity of the data." > > The integrity of the data can be divided into two aspects: ensuring the > data remains constant (unaltered) while stored, which is the > responsibility of the operation system and the database software, and > the data's integrity from an application perspective. Junk-in always > causes Junk-out even when using 'non-dumb' databases :-) Thing is, that's just not true. Junk-in *can* cause junk-out, or it can cause a runtime error and refuse to let you store the junk. I'm biased in favour of the latter, but you're not going to get that unless you load your database with more logic. By all means do things your own way, nobody's going to stop you. jh