Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: OO concepts and relational databases

by jZed (Prior)
on Aug 02, 2004 at 17:24 UTC ( [id://379338]=note: print w/replies, xml ) Need Help??


in reply to OO concepts and relational databases

You wrote:

Entity Attribute Value

While there are some cases in which this is a good idea, it can also lead to really confused things like this:

Entity Attribute Value
Elephant Color Gray
Workstation Linux_distro Debian

What happens to constraints and data types when each new row potentially introduces a new data type? What meaning does the concept "entity" have if there are no limits on the kinds of attributes it can take and the range and type of data the values for those attributes can have? I realize that you know what you're doing and probably only use this kind of a table in appropriate circumstances (and you did specify an example in which there were multiple optional attributes which is not the same as the example I've shown), but this kind of design seems to be a favorite with beginners who don't realize that it can sabatoge any notion of structure in the data.

You wrote:

Storing the optional attributes as columns requires a database change for every new attribute.

The ability to change the structure of the database is an essential feature of relational databases. Sure, you want to avoid it when you can, but to label it a bad thing (tm) throws out the entire relational baby with the bathwater.

Replies are listed 'Best First'.
Re^2: OO concepts and relational databases
by BrowserUk (Patriarch) on Aug 02, 2004 at 18:31 UTC
    The ability to change the structure of the database is an essential feature of relational databases.

    Very much so. And that is one (of several) good reasons why SQL should not be embedded in application programs. Leastwise, not object oriented ones. And application programmers should not be designing DB schemas.

    Applications (should) deal with application objects. Objects represent state, and flows of state, not data nor relationships.

    That doesn't mean that RDBMSs can't be used to underpin application programs. It just means that there should be an interface layer between the application program and the SQL.

    The make-up of the schema (tables and columns) is driven by the relationships inherent in the data. Different applications have different requirements of each relation. Read the bank balance; credit it; debit it; erase the entire relationship.

    The most prevelent and effective mechanisms for these are writable views and stored procedures. Just as the Class decouples the user code from the internal representation, so views and/or stored procedures decouple the Class from the datastore schema.

    That allows the DBA to amend the schema to incorporate new requirements for new applications, and tune it for a broad range of existing applications. Each application can have different logical and performance requirements, as well as different privilege levels to any given table or column.

    The impedance between most development languages, procedural and object oriented, is at so many level--security, data integrity, concurrency and latency--that using them to directly manipulate relations is like using oven mitts to do watchmaking.

    The only programming language I am aware of that really has the syntax and semantics for dealing with relational data natively is APL. It's set operators are very well matched to relational theory.

    SQL is not (in my book) a good interface between them. It is a handy language for relatively simple queries that interogate the relationships and make set adjustments to them, but as an abstraction layer, it sucks.

    Think of the times that you knew what you wanted to do, knew that the schema was capable of doing it, but get hung up on trying to frame the requirement into a form that SQL would accept. The frequency with which you will see large volumes of data pulled from a DB only to be subsetted with the application code highlights one level of impedance.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://379338]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (4)
As of 2024-03-29 00:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found