Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: 2 Jun 2006 12:06:30 -0700
<<<<I also don't see how particular SQL syntax quirks impede an ability
to write assertions(constraints).>>
I gave examples but they seem to be unsufficient... I will supply you with some code on that as soon as possible. >>
Actually, I have an example in mind that may be interesting...How do you implement a no-overlap operator constraint in SQL knowing that some NULL values are within a specific. Hint: try to answer this question using (CHECK, UNIQUE, FOREIGN KEY) and you will see what I am refering to.?
Thank you for your feedback.
> << In my opinion SQL does a fabulos job even with poor system of
> datatypes. VARCHAR2(20) what a humpback!>>
> You are rightfully entitled to your opinion so am I. I am not
> impressed at all by SQL for I face its limitations everyday. The fact
> that SQL is the best we have to get closer to relational implementation
> does not make me happy. Quite the opposite in fact.
> <<I also don't see how particular SQL syntax quirks impede an ability
> to write assertions(constraints).>>
> I gave examples but they seem to be unsufficient...
> I will supply you with some code on that as soon as possible.
> Complex assertions can even be implemented via basic
> > constraints (CHECK, UNIQUE, FOREIGN KEY) on materialized views.
> Yes but at what cost?
> Redundant non intuitive code when constraints get more exhaustively
> Breaking independence between the physical and logical layer
> (materialized/indexed views)
> *Complex* is a relative thing. Can you define user defined operators
> using SQL ? How do you define a data type as being another relvar
> using SQL ? How would the SQL DBMS implement operators on that? -->
> It can't.
> <<Again, overthrowing SQL would require a deaper insight.>>
> Overthrowing SQL is not the point and it is not the intent. My intent
> is about trying to identify in OO mechanisms that could be useful
> paliating at known SQL weaknesses.
> <<For example,
> what if we treat functions as relations? Shouldn't we write
> select ename, sal2 from emp, (sal2=2*sal) f
> where f.sal = emp.sal
> as a "pure" relationaly styled version of
> select ename, sal*2 from emp>>
> I do not understand what you are actually
> Is allowing predicates in the "where" clause give us any benefits?>>
> I am not positive what you mean by the two last questions. Thank you
> for rephrasing them. I do not understand what predicate have to do
> with where condition.
> Please do not consider me as anti-SQL as I am not. Just aware of its
Received on Fri Jun 02 2006 - 21:06:30 CEST