Re: SQL
- From: "topmind" <topmind@xxxxxxxxxxxxxxxx>
- Date: 26 Jan 2006 22:24:05 -0800
(part 2 of reply)
>
> >> 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.
>
> Well, a 'project' falls apart into many 'tasks'.
Perhaps. But the DB can still carry a large load without having to
carry all of it. Dumping it just because it cannot carry the entire
load by itself is dumb.
Dump the Yin just because it is not Yang also?
>
> >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).
>
> ... whereas for writing a large application, you might never need anything
> beyond a single programming language, if that programming language is a
> general-purpose one.
Well, I have not seen very many non-trivial apps that could not make
use of a DB and/or table engine at least somewhere.
>
> You're just showing that your 'hammer' analogy is falling apart, beceause
> of the differences between physical tools and software development ones.
If it falls apart, nail it back together.......with a hammer. See, it
even fixes criticisms.
>
> >> 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?
>
> As I mentioned above, in many physical disciplines, it is extremely
> difficult to put together anything that is a general-purpose tool,
> precisely because the tasks are so completely distinct.
But being TC does not mean convenient even if possible. It is possible
to create almost any furniture with a single (strong) carving knife if
you have enough patience and big trees. TC is the same way: it says
nothing about convenience or efficiency.
Thus, a carving knife is "Furniture Complete".
>
> >> 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?
>
> My 'toolchest' includes C, C++, Objective-C, Logo, Pascal, Simula,
> Smalltalk, Miranda, Haskell, Perl, Python and SQL (among other things).
Or objects.
>
> >> 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.
>
> RDBs stink for writing flight simulators. Ever tried it?
This comes back to the response time max threashold issue again.
However, I can imagine using a DB to store flight
scenarios/paths/situations/obsticals. Maybe each scenario would have to
be read into RAM, but it may not be practical to put them all in RAM,
and thus a DB to keep track of them and maybe find the best match based
on the user's previous flight, something files may not be good at
because the "indexing" would be on multiple factors.
>
> And I'm not just talking about the lack of support for joysticks or 3-d
> graphics. A flight simulator _could_ use a relational database to store
> the state of the simulated world, etc, but the end up being written using
> specialized data structures - because the relational data model doesn't
> fit well with the way one would model a plane, the world it flies in, etc.
> Yes, you _could_ store it in a relational database, but direct references
> between different parts of the plane, the different parts that make up the
> environment, etc, simply work better.
Some GIS systems use RDBMS.
>
> There are also many problems where the choice of using a RDBMS is made
> simply because it is there and thus readily available, i.e., just for
> reuse purposes, rather than because the data fits particularly well into
> the relational model.
>
> My main use of SQL and relational databases is actually for persistence -
Gee, I would have never guessed.
> often through an object-relational mapping tool (Apple's 'Enterprise
> Objects', part of their WebObjects product). This allows me to use the key
> strengths of RDMS:es - persistence, organization of data, and through SQL
> a relatively standard interface - while also allowing me to use the
> strengths of OO, for implementing the business logic for those objects
> that are stored in the database.
Strength of OO? You are talking to the wrong guy. oop.ismad.com
> But make no mistake: The database is a
> _useful_ part for storing the data, but it isn't a _necessary_ part. Other
> persistence mechanisms could be used.
OO'ers tend to use very little of what DB's can offer. They like to
reinvent the other items on that list outside of "persistence" just
because they can. If you want to have fun, look at how OO apps tend to
implement many-to-many relationships.
>
> >> 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?
>
> Exactly: You don't _need_ databases, per se, when using Java, because you
> can write your own, if necessary. And indeed, for some aplications, you
> can write something that will work _better_ for that application than
> using a RDBMS.
I doubt the economics are for it most the time.
>
> >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.
>
> Or one could just use one that has already been written - in Java:
>
> <http://db.apache.org/derby/>
One could write a DB in any TC language.
>
> >> 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.
>
> What precisely besides data storage and access is the relational model
> about? You should take note that I wasn't referring to persistence above.
> It's certainly not about computations or business logic or user
> interaction, for instance ...
What do you mean "not about business logic"? I've seen complex IF
statements that could be reduced to table attributes. Sure, something
has to "run" those indicators, but the runner is just like a player
piano: it does not care what the actual notes are in the paper roll, it
just "executes" them. The knowledge in your brain can be represented as
attributes in neuron tables.
table: Links
=================
sourceNode_ID
destinationNode_ID
weight // weighting factor, can be negative in some models
table: Node
===============
node_ID
activationFuncIndicator // (unit_step, sigmoid, piecewise_linear,
gaussian, and identity)
activationWeight // the "volume" given to activation function
Now, whether all "IF" statements should be turned into table attributes
and set logic is a separate issue. The fact is it can be and is done to
various levels.
What I put in code and what I put in tables is mostly a decision about
what is most convenient, not what is possible. They are generally
*interchangable*. (Putting 99% of the app in tables is generally
creating a table-oriented interpreter for the most part.)
Generally I use program code for Boolean statements. Boolean statements
are usually combersome to represent and manage in tables.
>
> >> 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.
>
> But it shows that you cannot use a relational database alone as a
> replacement for text files: You also need some form of parser to separate
> the text file into parts that you can put into the relational database.
So? Maybe that kind of parser is not something best done with a DB.
However, it is perhaps prudent to store a complex grammar in a DB.
>
> >> 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.
>
> Not necessarily - please don't put words into my mouth. The point is that
> SQL was never intended to work with arbitrary streams of characters - it
> was intended to work with arbitrary tables (and rows and columns).
But one *can* represent text as rows and columns. Maybe it is not the
most convenient approach in some cases, I will agree.
>
> >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.)
>
> Um, no. You wrote 'general purpose string matching/finding tool': Even by
> your own writing they are 'general purpose' _only_ within their specific
> domain, 'string matching/finding' - in exactly the same way as SQL is
> 'general purpose' _only_ within its own domain, 'accessing data in a
> relational database'.
I don't think this will be settled without specific use cases. The
issue of can/can't is getting mixed up with easier/hard.
>
> The point here isn't turing-completeness, actually: it's that some things
> only apply to _specific_ domains (such as regular expressions, which apply
> to the domain of strings;
I am not sure if I would call string handling a "domain" in the sense
it is usually used. Strings are a general-purpose tool also, BTW.
> and SQL, which applies to the domain of
> relational databases), whereas other things are defined to apply _in
> general_ (such as object-orientation, functional programming, procedural
> programming, etc). This is a very important distinction.
Well, OOP only applies to the domain of objects. How is seeing most
things as objects worse than seeing most things as tables? And don't
bring in the "behavior" argument again. We've been over that already.
You haven't shown how OO better handles behavior anyhow outside of
shape, animal, and device driver examples.
>
> // Christian Brunschen
-T-
.
- References:
- Prev by Date: Re: SQL
- Next by Date: Re: OOP phrases
- Previous by thread: Re: SQL
- Next by thread: Re: SQL
- Index(es):
Relevant Pages
|
