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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
