On Thu, 2011-09-15 at 10:35 +0100, John Hodrien wrote:
> On Thu, 15 Sep 2011, Always Learning wrote:
>
> > Golly. I grew-up in real computers. Relational databases are simply
> > database structures, linking records. There is no reason to use joins
> > and views IF the database is carefully planned. Joins and views are
> > another overhead. Rule Number 000001 in programming is Keep It Simple.
> Next you'll be saying you don't use triggers and constraints either.
Not consciously. Never heard of them.
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%
2Frzahf%2Frzahftrigcontable.htm
"A trigger is a type of stored procedure program that is automatically
called whenever a specified action is performed on a specific table.
Triggers are useful for keeping audit trails, for detecting exceptional
conditions, for maintaining relationships in the database, and for
running applications and operations that coincide with the change
operation."
> There's nothing wrong with using a database as just a dumb datastore,
> but you get out exactly what you put in.
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 ?
> Suddenly your application is responsible for a whole lot more. You
> might see a view as complicating things, but if it can make your app
> faster, and make your code cleaner, what's not to like?
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.
> 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 :-)
--
With best regards,
Paul.
England,
EU.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
