Re: OT: SQL

On May 4, 11:50 pm, Charlie-Boo <shymath...@xxxxxxxxx> wrote:
On May 4, 12:24 pm, Marshall <marshall.spi...@xxxxxxxxx> wrote:

On May 4, 7:25 am, Charlie-Boo <shymath...@xxxxxxxxx> wrote:
The idea of using preexisting files of arbitrary structure
as part of a dbms is so spectacularly bad I am speechless.

Why?

You have an application that works.

If you have an application and it works, you are in no
need of any further software. This is not the use case
that anyone worries about, because what you describe
is a non-problem.

The use-case that matters is: you have a spec and
you want an application.


Then Codd comes along and says to use his
system to process queries against its data.

He says to copy the data into flat files and pointers to them.

That bears no remotest resemblance to anything Codd said.

Codd proposed relations as a logical model. You are talking
about physical implementations. Until you can learn to make
the logical/physical distinction, you are not going to be able
to have a useful conversation with anyone who knows what
they are talking about in data management.


I say to use the original files where they are.

This idea of "original files" you have is obscure. I have
no idea what use-case you have in mind. I have never
encountered a situation where there was anything I
could call "original files." Data management is about
managing application data, or enterprise data, or
whatever kind of data. It is not about managing files;
that's what a filesystem is for. If your particular
application's needs are adequately met by a filesystem,
there is no reason to think that you need a dbms.


Which is better and why?

For any question, "which is better" is dependent on the
specifics of the situation. For a broad class of problems,
the relational dbms provides significant benefits. By and
large, these benefits do not include things like high
performance against one particular application-specific
query. A dbms is a *general-purpose* data management
engine. It is always possible to construct a special-purpose
device to outperform a general-purpose device for that
particular special purpose. Have you noticed that an
CPU is a general purpose computing device, and can
be outperformed with lower transistor count, lower cost
and less electrical consumption by a custom-designed
ASIC? Does that mean we should all ditch our laptops?


1. He forces you to copy the data - keep it twice. I don't.

Again, this point depends on the idea that you have these
"original files", whatever they are, and that you'll still need to
keep them even after the data they contain is in the dbms.
I don't see how that would ever be the case. (Maybe you
keep them for archival purposes.)


2. His way will be slower for several reasons:
a. You have designed it based on its particular spec. He has a
general system that doesn't know anything about the peculiarities of
that data.

Duh. Again, if you already have a system that is meeting
your needs, it is pointless to discuss changing it unless there
is a compelling reason to do so, which you haven't mentioned.
You're strawman does not describe the situation anyone is
actually in.


b. Your system design was created by people with computers. His
system design was created by the computer only - it uses only the
algorithms built into the Codd system.

To the extent that what you said above means anything, it is
wrongly reasoned: any algorithms or data structures that can
be implemented in a special purpose system can also be
implemented in a general purpose system. All that one would
then need would be physical independence to take advantage
of that. Since you don't know what physical independence
means, you're not in a good position to understand this point.
But I would suggest you look into this idea; I predict you'll
really like it.

To the possible counterargument that such things don't happen,
I can say from experience that they do. I have seen massive
running systems, built against an rdbms, head off scalability
issues by replacing out-of-the-box table handlers with ones
custom built for a particular class of application data. The
replacement table handler used a hierarchical store, so it
had a built-in performance bias, designed to be in favor of
the kind of queries we actually ran. But it had no expressive
bias, because the front-end remained relational.


c. He uses only flat files and pointers to them.

This is just flat-out wrong. Again, I have the direct experience
of using a hierarchical store. Also, you have companies like
Michael Stonebraker's latest venture, Vertica, which uses
a column-store. Do you know who Stonebraker is?


You can also use
hierarchical files and files with conditions placed against the data
in them - the examples I gave earlier: a file of all employees who
earn more than their manager, or of all those who do not, or all
emplyees who have a manager.

And I pointed out that materialized views are well understood and
commercially available today, in relational products.

Also, I'm going to have to play the Duke Nukem Forever card
against your position. You talk as if writing a commercial grade
dbms (relational or otherwise) is no big deal. So, where's yours?
Not papers. I want software I can run and evaluate, not something
made of unobtainium.


In all cases, your programmers designed and optimized your system
based on its particular characteristics. You have the advantage of
knowing these peculiarities. Codd's system was designed independent
of your database and doesn't have that knowledge when it runs. He is
wedded to main files plus indexes. You can use anything.

A relational system possessed of physical independence can also
use anything as its implementation technique. Tie.

A file is a braindead data structure. It's nothing more than
a finite mapping from the natural numbers to bytes. (Which is
a relation, I might point out.) It supports only three operations:
read, write, and seek. You're championing the pointy stick
against the guy with the M-1 tank. Hold still for a second; I
want to hit your argument with the main cannon and not have
to fire up the .50 cal.


Marshall
.

Relevant Pages

  • Re: OT: SQL
    ... as part of a dbms is so spectacularly bad I am speechless. ... they are talking about in data management. ... A dbms is a *general-purpose* data management ... CPU is a general purpose computing device, ...
    (sci.logic)
  • Re: Application logic and Business logic
    ... >>multiply matrices any close to O. ... > The same as if you use a distributed DBMS with a module that is a DLL. ... No it depends solely on the facts of linear algebra. ... > Data management is, and if computerized data management is not ...
    (comp.object)
  • Re: Base Normal Form
    ... > everything into the dbms. ... while programming languages have had a much freer development path. ... it comes to what they can do with data management. ... is a disaster for scalability. ...
    (comp.databases.theory)
  • Re: Searching OO Associations with RDBMS Persistence Models
    ... RDB is about data structure an OO is about ... RDB is about data management and OO is about application ... The DBMS must enforce all the business rules. ...
    (comp.object)