Re: Mixing OO and DB

On 21 mar, 23:23, Patrick May <p..._at_spe.com> wrote:
> frebe <freb..._at_gmail.com> writes:
> > On 19 Mar, 22:31, Patrick May <p..._at_spe.com> wrote:
> >> frebe <freb..._at_gmail.com> writes:
[Snipped]
>
> That is incorrect. Previously someone suggested that a general
> ledger could use a content management schema. That was a ridiculous
> thing to say and completely unrelated to this discussion.

> To give an example of decoupling, consider a clearing and
> settlement system. The schema holds customers, accounts, positions,
> books, trades, instruments, and other information related to the
> clearing and settlement of financial transactions. Some of the
> business logic is best expressed as operations on directed graphs
> (eliminating cycles to create a directed acyclic graph, identifying
> liquidity bottlenecks, selecting the transactions to settle, etc.).
> These graphs need to be dynamically updated and are sufficiently large
> that recreating them for every operation is prohibitively expensive in
> terms of performance.
BS prove it.

> The model used by this application is significantly different
> from that stored in any relational schema. Decoupling them is
> essential to the performance and maintainability of the system.
BS. You keep no repeating like a drone that *decoupling improves performance* but you have not provided a single proof of that.

> >> >> Since you agree that multiple different physical schemas are
> >> >> possible, decoupling the application from any particular set of
> >> >> those is both possible and good design.
>
> >> > Multiple logical schemas are also possible. The decoupling is
> >> > done using views.
>
> >> That's one way. Non-relational languages provide others.
>
> > So we have an agreement that using views is a valid solution for the
> > problem?
>
> It is one valid solution for some instances of the problem. It
> is not universally applicable. Do you disagree?
>
>
>
> >> > I thought that Brians examples with coordinates was pretty
> >> > obvious, but maybe some futher clarification is needed. Suppose
> >> > you have a table for Cartesian coordinates. Now you have an
> >> > application that needs to work with polar coordinates
> >> > instead. The solution is to create an updateable view for polar
> >> > coordinates, which derives the data from the original
> >> > table. Another solution could be to create a new table using
> >> > polar coordinates and creating a view (with the same name as the
> >> > original table) providing the Caresian coordinates. The logical
> >> > schema will now contain two relations for the same data in
> >> > different format.
>
> >> Alternatively, the data could be loaded into an object that
> >> does the conversion on demand. The rest of the application
> >> wouldn't need to know about the database or the specific schema at
> >> all.
>
> > And the benefit with that is?
>
> An object can convert any coordinate, without extra views or
> storage. What is the disadvantage of this approach? What is the
> clear benefit of using relations?
BS how does an object *coordinate*?

> > I will give a short example of why I think views are a better
> > solution than wrapping every SQL statement in a method.
>
> > Lets take Martins famous find_employees_eligible_for_retirment
> > example.
>
> I'd like to hear your explanation in the context of coordinate
> conversion, as well.
>
>
>
> > We have two solutions, one is to create a method.
>
> > find_employees_eligible_for_retirment()
> > {
> > return query("select id, name, birthdate from employee where
> > yeardiff(now(), birthdate) > 60)");
> > }
>
> > The corresponding view would look like:
>
> > create view employee_eligible_for_retirement as
> > select id from employee where yeardiff(now(), birthdate) > 60
>
> > In the first example the set of attributes is fixed (id, name,
> > birthdate), and the only way to get extra attributes (or join extra
> > tables) is to make another database call for every employee.
>
> > Using a view you could easily join extra attributes without making
> > extra database round-trips and have superior performance.
>
> > select e.id, e.salary
> > from employee_eligible_for_retirement r join employee e on e.id=r.id
>
> With a function wrapper, you could just create another SQL
> statement. If you found yourself repeating the retirement criteria,
> you could encapsulate that, perhaps even using a view, so that it is
> shared by both functions.
Only an idiot could suggest that creating another function wrapper is more intelligent than creating a new view.

> You seem to be making the assumption that there will be a
> proliferation of these functions. That's not the case in practice.
So are views.

> The ad-hoc querying capabilities of SQL are simply not required in
> most applications. Given that, there are some significant advantages
> to decoupling the application from the schema:
>
> - Functions (or methods) provide descriptive names.
Views can also be named the way we want.

> Many
> enterprise database schemas are relatively complex, making the
> SQL statements to accomplish something like reading all
> employees eligible for retirement less than intuitive.
BS.
In what digging into a wrapper intermixing XML, Java and SQL is easier to read than a SQL statement.

> - The application is insulated from changes to the business rules
> maintained by the database. If the criteria for retirement
> eligibility changes, there is no need to change existing,
> working, tested code that uses the function. Only the function
> itself needs to be regression tested.
Requirements are the core of the system. Are you saying that a part of the company/system should follow them and another discard them.

> - The function can return the data structure required by the
> application, which is unlikely to be the tuples returned by the
> database query.
Idiotic. A view returns what it is told to return.

> > Lets say you want to se how many employees in a specific department
> > that are eligible for retirement, you could easily write another SQL
> > query.
>
> > select count(*)
> > from employee_eligible_for_retirement r join employee e on e.id=r.id
> > where e.department=?
>
> > Using your method, you would have to write a new method for every
> > single SQL statement, duplicating the eligible_for_retirement
> > business rule all over you "persistence layer". The other option
> > would be to use the original find_employees_eligible_for_retirment
> > method and performing post-processing having terrible performance.
>
> Eliminating duplication is a good reason to encapsulate the
> database-specific components. The encapsulating functions can use
> views or any other techniques required to eliminate duplication at
> that level, and the functions themselves eliminate duplication within
> and across applications.
BS. In what wrapping is easier to eliminate in a distributed?.

> >> > On the logical level, virtually any data can be represented in a
> >> > relational form.
>
> >> On the logical level, all Turing complete languages are
> >> equally powerful. For particular applications, some are far more
> >> expressive and usable than others. Similarly, the relational model
> >> is not always the most expressive for a particular application.
>
> > Can you give some examples of data that doesn't fit for the
> > relational model on the logical level?
>
> That's the wrong question.
No moron that is the right question you are elluding because of your dishonnesty.

> Can I give an example where the
> relational model is not the most expressive and usable form of the
> data? Yes, see the clearing and settlement example above.
No you idiot. Anything you state is meaningless and baseless. Keep your crappy examples to uninformed audiences.

> >> >> There is therefore a need to translate between the data
> >> >> structures, which is another good reason to decouple the
> >> >> application from the specific physical schema being used.
>
> >> > Since the application is not dealing with the physical schema, it
> >> > is not able to do that translations. It is already done in the
> >> > RDBMS.
>
> >> That is not correct. The application deals with a specific
> >> schema with data represented in the relational model. That is not
> >> always the format required by the application.
>
> > What is incorrect? The fact the the applications access the logical
> > schema?
>
> The claim that the application can't do translations is
> incorrect, on its face. SQL isn't going to return DAGs, or even
> queues, stacks, or maps.
queues, stacks ans maps are low level problems that SQL does not have to deal with.

> Sincerely,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc. | Large scale, mission-critical, distributed OO
> | systems design and implementation.
> p..._at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Sat Mar 22 2008 - 00:38:32 CET