Re: SQL
- From: "topmind" <topmind@xxxxxxxxxxxxxxxx>
- Date: 23 Jan 2006 18:18:52 -0800
Christian Brunschen wrote:
> In article <1137996532.423030.167400@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> topmind <topmind@xxxxxxxxxxxxxxxx> wrote:
> >(Part 1 of reply)
> >
> >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.
>
> You are still using a persistence mechanis; you're just choosing to not
> use it for persistence.
Again, persistence is one of MANY features of a DB.
> A file system is a persistence mechanism; lots of
> applications put data into temporary files, which they delete after
> they're done with them, sometimes because the available storage in the
> filesystem is larger than in main memory (Photoshop, I believe, used to do
> that, and maybe still does). This non-persistent use of the filesystem
> doesn't make a filesystem any less of a persistence mechanism.
They usually do that because the RAM system is limited, not because
they want any special features of the the disk system.
>
> The relational model, and SQL, were developed specifically for persistent
> databases.
Because RAM was too expensive to consider non-persistence DB's back
then. The history is generally irrelavent. I don't care what they did
in 1965; It does not change what I do now. LISP was originally a
demonstration tool only. The author never set out to create a new
production language. But LISP fans are not going to be halted by
ancient intentions.
> You can use them in a non-persistent manner, but that is
> essentially using them contrary to their original intent and purpose.
DB's have a lot of features *besides* persistence, and I use DBs for
those features. Label DB's whatever you want, but I find those other
features useful. You guys are playing a label game. Focus on potential
usage, not your pet classification or what happened 50 years ago.
>
> By the way, how do you create and destroy these temporary tables? i.e.,
> does the dbms manage their lifecycle for you, creating them as necessary
> and removing them when you no longer need them, or do you have to perform
> either or both of those steps yourself?
Some table-oriented tools auto-delete them, some are RAM-only, while
others require manual intervention. (The ideal system would offer all
of these options.)
> >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.
>
> Relational Databases and SQL are tools for the specific task of storing,
> accessing, modifying data - they are single-purpose tools (see definitions
> below). They are 'general-purpose' _within their specific area_, as they
> are not specific to any particular data access/storage/manipulation tasks,
> but they are 'general-purpose' _only_ within their _specific_ domain,
> which is the storage of data.
Bull.
> A 'general-purpose' programming language is
> one that allows one to write solutions to essentially arbitrary problems
> using it, possibly with some specific exceptions (such as, 'python is a
> general-purpose programming language, but due to its interpreted nature,
> it shouldn't be used for writing interrupt handlers').
You mean "Turing Complete". We have been over this already. I don't
expect a query language to be TC to be considered "general purpose"
because one can and perhaps should use multiple tools such that one
should not EXPECT to have one tool/language do everything. Your "do
everything" assumption is a poor assumption.
>
> One thing to remember is that a RDBMS does _not_ do _anything_ that one
> can't do in code on one's own - they are essentially just a pre-written
> library, with a little domain-specific language as part of its interface -
> whereas on the other hand, _most_ of the things you can fo in _code_,
> _cannot_ be done in an RDBMS.
Irrelavent. I don't assume a single tool has to carry the entire load
of an app.
> >> > 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.
>
> Yes, but you wouldn't expect to be using the hammer _unless_ you
> encountered a problem that _specifically_ included nails.
Not true. They are good for pounding things into place, pounding them
out of being stuck, prying things off (with the back end), etc.
> If you
> encountered problems that included only screws, you'd never touch it;
> you'd be using your screwdriver set instead.
By that definition nothing can be "general purpose" because you are
incorrecting looking for an all-in-one tool. (A Swiss Army Knife is
actually a collection of many tools, not one tool.)
>
> >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.
>
> *sigh* Time for some rudimentary definitions:
>
> single-purpose
> useful for a single purpose, for a specific task, only
>
> multi-purpose
> useful for a number of specific tasks, but only a limited number still
>
> general-purpose
> useful for most tasks in general, though possibly with some specific
> exceptions
Okay, but even your own def does NOT require it to carry the entire
load, but simply be *used* for most things.
>
> all-purpose
> useful for absolutely everything
>
> A hammer is _not_ a 'general-purpose tool', because it isn't intended
> or useful for general tasks, but specifically for beating nails into
> stuff.
I consider the equivalent of an app to be a "project", not a task. For
an entire project, such as building a car or a house, most likely you
will need a hammer at least once (even if you don't use nails).
> If it also has a back end that lets you pry nails out, it might be
> considered a 'multi-purpose' tool, but even that would be a stretch,
> because you're still only working on the 'nails' bit. Either way, it's not
> a 'general-purpose' tool by any stretch of the mind.
Is there such a thing WRT physical tools by your def?
>
> Actually, there's a saying that's apt, and which I think that 'topmind'
> very clearly exemplifies:
>
> "If all you have is a hammer, everything looks like a nail"
Like maybe.......Java?
>
> The point of which, of course, is precisely that a hammer is _not_ a
> general-purpose tool, but that if you are accustomed to working only with
> a specific limited toolset (and thus the associated set of problems it is
> intended to solve), there is a tendency to try to see all other problems
> as if theyy, too, were problems of that specific type. However, that is a
> fallacy, as there are problems which clearly don't fit into such a narrow
> mold.
That can apply to anybody. If you are truly experienced such that you
tried them all, then you could point to multiple areas where RDB'S
stink.
>
> Even topmind's own comments above show that he is fundamentally aware of
> this: he says that a hammer is _one of_ the tools he would pack, so he
> recognizes that there are many more tasks that he might encounter, but for
> which a hammer is not a useful tool. But he confuses 'general-purpose'
> with 'one-size-fits-all': Those are _not_ the same.
No, it appears to be you who is making that part of the definition.
>
> Of course, when it comes to computers, 'general-purpose' can frequently
> come very _close_ to being 'all-purpose' simply because there are very few
> problems that fall outside the 'general-purpose' area.
>
> Java is a 'general-purpose' language, because you can write all sorts of
> programms in it - from math-intensive scientific number-crunching, to data
> storage and access, to graphical user interfaces, to distributed systems,
> to ... etc. SQL _isn't_, because there are _vast_ areas of problems that
> SQL not just osn't intended to address, but simply _cannot_ address,
> however much you try to make it.
Addressed above.
>
> The need for 'yin-yang-complementary' tools arises in cases where it it
> difficult to create multi-purpose or general-purpose tools: construction,
> woodworking, metalworking etc, are all places where it is difficult to
> create such tools.
Are you saying that in Java you don't need DB's because you can write
your own concurrency management, join systems, aggregation systems,
etc? Perhaps, but that just means that you reinvented the DB the hard
way, and a proprietary one that new comers have to learn from scratch.
Reuse is out the door.
[snip]
>
> And again, 3GL can be used to _write_ RDBMS; the converse is _not_ true.
Irrelavent.
>
> The relational data model is specifically intended for data storage and
> access; it isn't intended to address anything beyond that.
If that was true, then they would be happy with a file system alone.
Besides, original intentions can mean squat, per above.
[snip]
[re: Text schema example]
> But then you have taken what was an arbitrary stream of characters and
> already broken it up into a representation that better suits your specific
> model.
Nothing wrong with that.
> And I suspect that the code that would read an arbitrary stream of
> characters and puts it into your tables, was written in something _other_
> than SQL - because SQL is not good at the free-text processing that is
> necessary to get the data into a tabular format, because SQL is not
> general purpose.
You mean not Turing Complete, per above. Something does not have to be
TC to be "general purpose". Another example would be Regular
Expressions. They are not TC, yet are a general purpose string
matching/finding tool. (Maybe not the best either, but that is another
story.)
[snip]
>
> // Christian Brunschen
-T-
.
- Follow-Ups:
- Re: SQL
- From: Christian Brunschen
- Re: SQL
- References:
- Prev by Date: Re: SQL
- Next by Date: Re: SQL
- Previous by thread: Re: SQL
- Next by thread: Re: SQL
- Index(es):
Relevant Pages
|
