Re: S.O.D.A. database Query API - call for comments

In comp.databases Todd Gillespie <toddg_at_linux127.ma.utexas.edu> wrote:
> *sigh*.. You must have missed that day in class.

Sorry, long time since I was at the university.

> A table row is an instance of an Entity. An entity is often a real world
> object. Sometimes it is a concept, sometimes an action, always something
> you might model as an object.

relation=object, you mean?

Certainly table rows contain relations that should tell something about the real world. And certainly it's possible to store objects as one or more table rows.

Anyway, I think that a table row is close to worthless if you encapsulate it into an object in the database. I see no need to do that. Beeing able to join tables and do small selections is the major power with the relational model.

Said another way; the resulting rows from a query is usually very interessting, but often the "raw" rows of a base table doesn't belong anywhere else than in the database, ready to be used by queries.

Take a table with an ID of an employee, and an ID of a project the employee is working on. It's not useful at all to represent such a table row as an object.

> What does 'not useful for anything than making the database work' even
> mean, anyway? Are disks and idexes also therefore not useful?

Disks and indexes are needed to make the database work. The front end doesn't need to know about those things.

> We like to call that a function, or a stored procedure according to your
> flavor.

Function, procedure, stored procedure, method ... what to call it only depends on the paradigm. For SQL and DBMS'es, I'd call it "stored procedures", when beeing object oriented, it's "methods".

[my senior at my previous workplace told me to grab all data from two tables and do the joining in perl for performance reasons]
> Your co-workers were fools. I do not say this to insult, only to be
> honest. I have run into this myth several times in my career, and it is
> always hard to convince beginning programmers otherwise.

He was certainly very stubborn, and I was very amuzed both at this point of view and many other viewpoints of him.

I don't think he was right in the case where two tables should be joined, but he certainly was right when subqueries were involved. The DBMS stalled completely. It went pretty fast through perl, as long as the subquery didn't have a too big return-set.

Another issue - when telling (in a programming language) what the computer should do, it's always possible to analyze in advance how much resources the program will use, how long time it needs to run, and if it scales well or not. When telling (like in SQL) what data you want to see, you have no clue about how much resources and time the query will gobble.

> You should also be concered about bugs -- your former coworkers supposed
> that you or they can correctly implement SQL selection and sorting faster
> and better than people who have worked on it for 20 years.

In this case it didn't require much more work writing the perl code than writing the SQL.

Besides, that rotten DBMS we used probably hasn't existed for 20 years :-)

God knows why we used it. When I asked the abovementionated collegue about his plans for changing it out, he said he was already working with it - changing it out to flat files, not to another DBMS.

> Don't believe me? Put 10,000,000 rows into several tables in a database
> (a very moderate number).

That rotten DBMS didn't scale very well. Of course having 10M of records in a perl hash table wouldn't work out at all, but I also have some doubts that our DBMS would handle it.

-- 
Tobias Brox - freelancer for hire!
Programming, system administration, etc
+47 98660706 / tobiasb_at_suptra.org