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 adrianh (Chancellor)
on Aug 02, 2004 at 19:11 UTC ( [id://379388]=note: print w/replies, xml ) Need Help??


in reply to OO concepts and relational databases

But, as an implementation detail, it's ok to have instances of two different classes have some of the details of your checking account, if not the ability to modify it.

I'm not sure that I'd agree with that myself. In my experience duplicating application state in multiple classes leads to the same sort of problems that duplication in a DB cause.

If I see duplicate state in a class hierarchy my first thought would be that there is a missing abstraction to be discovered, and my second thought would be that this would be a good area to look for bugs.

Not that I disagree that "Database decomposition is very different from class decomposition", because it is ;-)

Well-written OO code is inefficient

I agree with what you're saying here, but it's nothing to do with well written OO code being inefficient. Quite the opposite.

If an application needs to open four database connections for four queries we have a bad design. Badly written OO code being inefficient isn't really surprising.

(Interestingly enough I've seen similar problems from the opposite direction - with RDBMS people doing OO coding and creating lots of unnecessary "join" classes leading to hideously inefficient bloated code. Again this says nothing about the relative efficiency of OO or RDBMS models - just that they're different and you need to use the right one in the right place.)

Getting the most out of a database is HARD

I don't think it is actually. Don't scare people away!

At least, it's not any harder than getting the most out of an OO decomposition, or getting the most out of a functional decomposition.

It needs to be learnt, and more people need to learn it, but the basics are not that complicated.

The hard bits about databases aren't really the general theory, but the nitty gritty specifics about individual implementations.

Classes are not tables and attributes are not columns

Amen. Twice. In bold. Underlined.

Too many OO developers treat RDBMS as suboptimal object persistence layers, which is kind of like treating a train as a suboptimal car. True, but somewhat missing the point.

Smaller applications and certain subsystems of larger applications which do not have a performance component can benefit greatly from the ease-of-development that CDBI provides. But, without a lot of customization, those kind of tools do not scale well.

I'm not sure what you mean by "scale well" here. I've certainly used CDBI in large production systems without any problems.

It's certainly not suitable to all systems (because it has that one-table-per-class concept built into its core), but where it is applicable it works well in my experience. Where it doesn't work well you can always hand roll your own, or use one of the more flexible OO-RDBMS mappers.

However, stored procedures, while within the database application, have very little to do with the core function of a database - data storage and retrieval. At best, they are syntactic sugar that can help maintain data integrity. But, that is a far cry from saying that databases have behaviors.

Maintaining data integrity can hardly be called "syntactic sugar"! (and what else are we to call stored procedures, triggers, etc. if not behaviour?)

Replies are listed 'Best First'.
Re^2: OO concepts and relational databases
by dragonchild (Archbishop) on Aug 02, 2004 at 19:43 UTC
    Maintaining data integrity can hardly be called "syntactic sugar"! (and what else are we to call stored procedures, triggers, etc. if not behaviour?)

    Data integrity is orthogonal to stored procedures and triggers. Data integrity is maintained by normalization and foreign keys1. Triggers and stored procedures are the ability to use a programming language that is supported by the database engine. They are not necessary for data storage or to maintain data integrity. In fact, the entire idea of stored procedures is marked as "implementation-specific" in the ANSI-92 standard.

    Now, triggers can be used to help maintain data integrity. The most obvious case is if you have a schema that has been deliberately denormalized for performance reasons. If you make a modification to table A, table B might need to be updated in an atomic fashion, to maintain the denormalization. However, that is outside the basic functions of an RDBMS.

    As for triggers and stored procedures being behaviors ... I still maintain they are not truly behaviors, in the OO sense. The table doesn't have a behavior that is associated with it. If anything, the behavior is associated with the action that triggers it, not the table the action was performed on.

    Another item to note is that certain things that require triggers and sequences in one RDBMS (Oracle) can be done with a set of keywords in another (MySQL). I'm speaking of the AUTO_INCREMENT keyword in MySQL that can only be duplicated by using a trigger and a sequence in Oracle. The keyword may be implemented as such under the hood, but it also may not. Regardless, it's still syntactic sugar.

    1. Granted, most RDBMSes implement foreign keys as triggers, but that doesn't mean that the triggers are necessary, or even sufficient, for foreign keys. MySQL, for example, requires that the referenced column have an explicit index on it (in the InnoDB tabletype), while Oracle does not.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

      Data integrity is orthogonal to stored procedures and triggers

      Depends on how you define data integrity. If I have a banking application where it should be impossible to update the value of the balance column of the current_account table without there being an appropriate entry in the debit or credit tables I would call it a data integrity issue, and enforcing it with stored procedures and/or triggers would seem a sensible option.

      The table doesn't have a behavior that is associated with it. If anything, the behavior is associated with the action that triggers it, not the table the action was performed on.

      I think I'll just have to say to-may-to / to-mah-to on this one. As far as I'm concerned when I do something like:

      CREATE OR REPLACE TRIGGER enforce_business_rules AFTER UPDATE ON current_account ... etc ...

      I'm doing something to the current_account table. YMMV :-)

        Triggers do not have to affect the table that they trigger upon. For example, we have a trigger that will add rows to other tables when the given table is inserted into. That has nothing to do with data integrity and everything to do with business logic. (You even named your trigger accordingly.)

        In my opinion, you are confusing business rules and data integrity. Data integrity is a set of rules about the form of the data, based on how the data moves. Business rules have to do with things like you discuss. Credits, debits, and balances are a business rule. Data integrity would require that every credit and every debit have a valid FK to the current_account table. Whether or not they balance is an application issue.

        This is actually a pet peeve of mine. Putting business rules into the datastore limits your options. You end up not being able to do the following:

        • change datastores (Oracle -> MySQL, for example)
        • safely upgrade versions of your datastore. (Oracle, for example, has had issues between point releases of 9i.)
        • support more than one type of datastore (should this be needed)
        • allow more than one application to use your datastore
        Not to mention that it's a huge maintenance headache, having to support more than one language and/or needing to have a DBA do development.

        That last item may be a bit confusing, so I'll explain the reasoning behind it. Most databases begin life supporting one application, so there's a bit of myopia involved in the design, especially of the schema and supporting triggers / stored procedures. Some places put a lot of the business rules into the database.

        So, let's say you do that and your database has been very successful. Now, your manager / VP / whomever wants you to add another application. Say, a reporting application for the clients, over the Web. Not a problem. But, now they want you to add the capability to have the clients update the data. Oops!

        You now need to scour every single bit of code within the database to make sure that seemingly simple data changes that the web application wants to make won't adversely affect your database because every time you made that data change within the internal app, you always wanted to do XYZ as well. It's much simpler to have a webservices-type design with N tiers. That way, each tier does one thing, one thing only, and does that one thing well.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        I shouldn't have to say this, but any code, unless otherwise stated, is untested

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2024-03-19 09:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found