Re: SQL

(Part 1 of reply)

> >>>>>SQL is not an implementation. What is the difference between locking
> >>>>>yourself to SQL instead of locking yourself to Java? If you want
> >>>>>open-source, then go with PostgreSQL. What is the diff? Java ain't no
> >>>>>universal language either.
> >>>>
> >>>>Of course it's an implementation! It implements access to physical
> >>>>storage.
> >>>
> >>>
> >>>Just as Java implements access to physical RAM etc.
> >>
> >>Exactly. Java is a specific implementation of a 3GL. 3GL is the
> >>abstraction, Java is an implementation. Persistence access is the
> >>abstraction, SQL is an implementation.
> >
> >
> >
> > Why do you keep saying "persistence"? I don't think you get the idea of
> > RDBMS and query languages. Like I said, think of a RDBMS as an
> > "attribute management system". Forget about disk drives for now. Saying
> > it is only about "persistence" is simply misleading.
>
> Persistent data is data that is stored externally between executions of
> an application. RDBs are a response to that need combined with a
> requirement that access be generic (i.e., the data can be accessed by
> many different applications, each with unique usage contexts). That's
> what DBMSes do -- they manage persistent data storage and provide
> generic, context-independent access to that data storage.


I disagree. You can use them that way, but I tend to view them as an
"attribute management system". They do well modelling "things" in the
real world (and virtual things) by keeping track of attributes of them.
They also provide important and useful services such as concurrency
management, joins (cross-referencing), sorting, and aggregation (sums,
counts, averages, etc.) Mere persistence does NOT have to include
things such as joins and aggregation, making one do them in app code
instead.

Back in my desktop-DB days, I created a lot of temporary tables to do
things such as joins, filtering, and aggregation for task-specific
temporary uses. The results were not kept beyond the task/module. Thus,
I was using DB tools *without* any sense of "lasting".

What would *you* call that? "Persistence" does not apply there.


>
> My point in this subthread is that such responsibilities are complicated
> enough in practice that one does not want the DBMS to also manage and
> execute dynamic business rules and policies. IOW, the DBMS should just
> mind its own store. [This thread has been a veritable hotbed of puns.
> I've probably made more in this thread than I've done in the last
> decade. B-)]

I agree that code does some things better and DB other things, and one
uses them *together* in a Yin-Yang fashion. They compliment each other.

>
> >>>>More important to the context here, that implementation is
> >>>>quite specific to one single paradigm for stored data.
> >>>
> >>>
> >>>Any language or API is pretty much going to target a specific paradigm
> >>>or two. I don't see any magic way around this, at least not that you
> >>>offer. UML is no different.
> >>
> >>4GLs get around it because they are independent of /all/ computing space
> >>implementations.
> >
> >
> > I am not sure UML qualifies as 4th Gen. Just because it can be
> > translated into multiple languages does not mean anything beyond Turing
> > Equivalency. C can be translated into Java and visa verse.
>
> A UML OOA model can be implemented unambiguously and without change in a
> manual system. In fact, that is a test reviewers use to detect
> implementation pollution. The OOA model for, say, a catalogue-driven
> order entry system will look exactly the same whether it is implemented
> as a 19th century mail-in Sears catalogue or a modern broswer-based web
> application. That is not true for any 3GL.

One can execute Java code by hand also. If you follow the spec, it
should always come out the same. (There may be minor vendor differences
due to errors or fuzzy areas in the spec, but this is true of any
non-trivial tech language, including UML.)

>
> >>However, that's not the point. SQL is a 3GL but comparing it to Java is
> >>specious because Java is a general purpose 3GL.
> >
> >
> > Again, this gets into the definiton of "general purpose". I agree that
> > query languages are not meant to do the *entire* application, but that
> > does not mean it is not general purpose. File systems are "general
> > purpose", but that does not mean that one writes an entire application
> > in *only* a file system. It is a general purpose *tool*, NOT intended
> > to be the whole enchilata.
>
> Huh?!? If you can't write the entire application in it, then it isn't
> general purpose by definition.
>
> > A hammer is a general purpose tool, but that does not mean one is
> > supposed to ONLY use a hammer. You need to clarify your working
> > definition of "general purpose", and then show it the consensus
> > definition for 4GL.
>
> huh**2?!? A hammer is not a general purpose tool by any stretch of the
> imagination.

Okay, then what is a "general purpose tool"? If I was going to put
together a tool box for a trip where the mission details are not given
ahead of time, I would certainly pack a hammer. Only an idiot would
not. No, it is not a one-size-fits-all tool, and I don't expect one.
Good apps don't need a one-size-fits-all language because they can use
yin-yang complimentary tools.


>
> >>SQL represents a
> >>solution to persistence access that is designed around a particular
> >>model of persistence itself. So one can't even use it for general
> >>purpose access to persistence, much less general computing.
> >
> >
> > Please clarify. Something can still be within a paradigm and be general
> > purpose. Further GP does not necessarily mean "all purpose", for
> > nothing is practially all purpose.
>
> SQL is designed around the RDB paradigm for persistence. It can't be
> used for, say, accessing lines in a text flat file because the text file
> is not does organize the data the way SQL expects. So SQL is not a
> general purpose interface to stored data. Apropos of your point,
> though, SQL is quite general purpose for accessing /any/ data in a
> uniform way from a data store _organized like an RDB_.

Well, I agree that SQL is probably not a very good way to reference
free-form text. However, just because it is not good for everything
does not mean it is not general purpose. Again, NOTHING is good at
EVERYTHING. Do you claim that there is something that is good at
everything? No? I didn't think so.

By the way, I have created tables similar to this:

table: textFile
--------------
fileID
ParagraphID
SentenceID
token (word or punctuation)
tokenType (punctuation, word, non-printable, etc.)

(Non-printable characters are represented in Hex notation.)

It can be done.


>
> >>>>Requirements -> 4GL -> 3GL -> Assembly -> machine code executable
> >>>>
> >>>>Everything on the left is a specification for what is immediately to its
> >>>>right. Similarly, everything to the right is a solution implementation
> >>>>for the specification on its immediate left.
> >>>
> >>>
> >>>Well that is a bit outdated. For one, the distinction between 4GL and
> >>>3GL is fuzzy, and many compilers/interpreters don't use assembler.
> >>
> >>My 4GL definition isn't ambiguous, which is why I like it. Reviewers of
> >>OOA models have no difficulty recognizing implementation pollution.
> >
> >
> > Argument by authority.
>
> I prefer to think of it as argument by rational practicality.

I didn't see it *here*.

>
> >>>>Go look at an SA/D Data Flow Diagram or a UML Activity Diagram. They
> >>>>express data store access at a high level of abstraction that is
> >>>>independent of the actual storage mechanism. SQL, ISAM, CODASYL, gets,
> >>>>or any other access mechanism, is then an implementation of that generic
> >>>>access specification.
> >>>
> >>>
> >>>SQL is independent of the "actual storage mechanism". It is an
> >>>interface. You may not like the interface, but that is another matter.
> >>>Repeat after me: "SQL is an interface, SQL is an interface, SQL is an
> >>>interface"....
> >>
> >>Try using SQL vs. flat files if you think it is independent of the
> >>actual storage mechanism. (Actually, you probably could if the flat
> >>files happened to be normalized to the RDM, but the SQL engine would be
> >>a doozy and would have to be tailored locally to the files.) SQL
> >>implements the RDB view of persistence and only the RDB view.
> >
> >
> >
> > How is that different than ANY other interface? You are claiming magic
> > powers of UML that it simply does not have.
>
> There is a distinction between describing an interface and designing its
> semantics. UML is quite capable of describing the semantics of any
> interface. Deciding what the semantics should be is quite another thing
> that the developer owns.
>
> When I have a subsystem in my application to access persistent data,
> that subsystem has an interface that the rest of the application talks
> to. That interface is designed around the rest of the application's
> data needs, not the persistence mechanisms. It is the job of the
> persistence access subsystem to convert the problem solution's data
> needs into the access mechanisms de jour.

I could wrap SQL calls in functions, like that PinkScarf example I
already gave. But unless the same kind of thing is called multiple
times, it is just code bloat. Query languages can be compact in many
circumstances. Putting bloated single-use wrappers around it gets you
nothing except more code. Thus, I *can* play the same game via function
wrappers if need be.

>
> If the persistence is an RDB, then the subsystem implementation will
> <probably> use SQL. If the persistence is flat text files, it will use
> the OS file manager and streaming facilities. If it is clay tablets, it
> will use an OCR and stylus device driver API. That allows me to plug &
> play the persistence mechanisms without touching the application
> solution because it still talks to the same interface regardless of the
> implementation of the subsystem.

Flat files don't have near the power. That is a poor analogy. RDBMS are
MORE than persistence. Say it over and over until it clicks in. Just
because YOU use it ONLY for persistence does not make it the only way
to build systems, just the bloated reinvent-the-wheel way JUST so that
you can claim UML purity.

>
> IOW, the semantics of the interface to the subsystem is /designed/ at a
> different level of abstraction than that of the subsystem
> implementation.


Bull. UML is often a LOWER level of abstraction because it can take
much more code/language to specify the same thing.


> UML doesn't care about the design process; it just
> represents the results.

Yeah right. Logic languages, like Prolog, once claimed the same thing
(and in some senses were right, but programmer productivity or code
size was not objectiviely reduced). UML is a visual language just like
any other language, including the likes of Lab View. Language ==
Language. UML is not magic. You got nothing new.


>
> > And as somebody pointed out, one can use SQL on flat files too. ODBC
> > drivers can be created to hook SQL to spreadsheets, flat files, etc.
>
> Only if the data is organized around embedded identity and normalized.
> Even then such drivers carry substantial overhead and tend to be highly
> tailored to specific applications. IOW, you need a different driver for
> every context (e.g., a spread***) and then it won't be as efficient as
> an access paradigm designed specifically for the storage paradigm.

So? What is the grand alternative? Of course different "devices" are
going to need different drivers. That is a given. There is no
one-size-fits-all driver. I have no idea what alternative you are
envisioning, but it is probably in the category with unicorns and
bigfoot.

(end of part one)

.

Quantcast