Re: OOP/OOD Philosophy

frebe wrote:
> > So you are saying that the paradigm can couple out to the other modules,
>
> It is almost impossible to decouple the database paradigm from the
> other modules, because changes in paradigm moves the border between
> the modules. If you have a high-level pardigm (relational) and switch
> to a low-level (hierachical) it is possible, because you know where the
> borders are and you know what type of logic that should be classified
> as "business" and "persistence". But the opposite is much harder.
>
> For example, it is resonable to think that the next generation of
> databases would have more (standardized) support for data validation
> using regular expressions etc.

Back in the 80s I thought it was reasonable to assume all the database
vendors would have standardized date functions ... 20+ years later is
still hasn't happened.

I was also hoping for standardized primary key generation (sequences),
nope, still waiting ...

Now what were you saying about regular expressions?

> logic. But in the future it would most likely be classified as
> "persistence" logic. Do you put your validation code in the persistence
> layer today, in an attempt to be prepared for the future?
>
> > even when the actual technology is insulated.
> The actual technology is not insulated. By using interfaces like JDBC
> you don't need to have any idea about the underlying technology. It may
> be everything from text files to DB2.
>

That's strange, in my experience every database is so different I'm
still worrying about everything.

Cheers.

.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... It is almost impossible to decouple the database paradigm from the ... The actual technology is not insulated. ... When you do software development you can't decouple from everything. ...
    (comp.object)
  • Re: Relational database & OO
    ... can be applied beyond the RDB's table/tuple paradigm. ... relationships in an RDB represent a specific implementation of the ... But no existing production database qualify as a relational database. ... Neither do the relational model or SQL. ...
    (comp.object)
  • Re: Relational database & OO
    ... The RDB Data Model and the solution's Class Model will typically be different for non-CRUD/USER applications because they need to be optimized differently. ... all the business systems I've participated coding or designing spent little production time changing data. ... Given statistics like these it makes little sense to design your application or OO model before designing your database. ... And OO Class Models are routinely normalized as part of the basic paradigm methodology. ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... If you're thinking of a CRUD system, ... No, I agreed that using a database for simple create, read, ... the design relative to using OO techniques, ... All this mixing paradigm stuff is irrelavent anyhow. ...
    (comp.object)
  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... Steele saying everything is a constraint and Harrop saying everything is a pattern and more than one failed language saying ... Every form returning a value is necessary for us to have the functional paradigm /available/ to us, and it is a fine paradigm, we just do not want to be enslaved to never changing state. ...
    (comp.lang.lisp)