Re: SQL
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Mon, 6 Feb 2006 19:59:22 +0100
On 5 Feb 2006 14:00:22 -0800, topmind wrote:
Dmitry A. Kazakov wrote:
I have answered this. If you can map relations to individual objects rather
than types, do it. Nobody proposes to invent types where unnecessary. A
program with a lesser number of types is easier to understand. The problem
is that quite often this is technically impossible. If you wish to force
everything into the limited set of types, SQL has, you must also accept
much higher developing costs and maintenance beyond anyone's capacity.
When I see an actual case with code from my domain, I might change my
mind. Types don't model biz things very well IMO.
They need not to. The whole point is that relational is typed as well. Full
stop.
Whatever advantages of modern typed systems could be used to improve (sic!)
existing typed (sic!) relational systems is another question. It is up to
developers.
How specificly is "types" different from "validation" in this example?
x = add("123","99.28");
y = add("foo","7");
The language does not care what "foo" is here. Only the "add" function
will care when it checks to see that the first parameter is a valid
number.
The above isn't properly typed. "123" has the type String. Strings aren't
additive.
Language can and do this. Label it however you want, it works.
Really? What is the result of add("fee", "123") ?
"1069"? "4201"? "fee123"? "sysadmin@xxxxxxxxx"?
There are other things it might check such as range because it
may not be able to add large numbers. Types cannot do this very well
unless we either pick arbitrary chunk sizes, or create a type for every
possible length/size, which is dumb.
Types do it perfectly. I can have a wide set of numeric types having
different models.
And long-winded confusing code to use it.
Huh, the code you presented is 1) longer, 2) far more confused.
It is a very important issue. Numeric types are models
and there could be many different models of integer, real and other numbers
as found in mathematics. Note that range is only one aspect here. There is
also precision, rounding, accuracy of numeric operations etc. Further typed
systems describe requirements on the type and the compiler/engine is
responsible to fulfill these requirements *automatically*. This way is far
more safe than adding "123" to "99.28", riddling if the result is
"12399.28".
The "protection" of heavy typing is not free. Often it requires twice
as much code as type-free code and longer coding time. With a type-free
language one can use the time left over from brevity and clearity to
spend on testing, unit tests, etc. Type-free code reads more like
psuedo-code. Type-heavy code reads like legalese.
As I have shown, it is not type free. It is typed in a definite way. How do
you know that this way is the proper one? Do you have use-tests to verify
that? Did you count all these tests? Where are use tests for accuracy,
rounding errors?
Businesses are run by scrooges: they want productivity at a low cost.
I'm sure, they know pretty well what risk management is.
Strong typing does not provide this.
SQL is typed, so I see no point.
but also utterly inefficient with respect of
space and time required for may operations.
When I encounter enough of such scenarios,
Put an image in relational table, so that each pixel would be a cell.
Put a program code in a relational table and write compiler in SQL
...
Why SQL? SQL is one of an infinite possible relational languages.
Fine, show us an outline of a better language limited to solely relations
and we'll see.
Further, relational does not dictate implementation.
Wrong, it puts definite limits of the implementation.
Show me a definite limit.
1. Row ID. It falls out of model, completely. In a truly relational model
you cannot mark either cells or rows, they have no identity of their own.
2. Tables of tables.
3. Generic programming in terms of sets of tables sharing common
properties.
If I am *searching* based on multiple factors, sure I'd be happy to use
a (good) table browser.
That's the point, you need a different paradigm, because "path" is not a
type in SQL. Because result sets aren't ordered in SQL, etc. Write a GPS
car navigation system representing the results as relations and try to sell
it *anybody*!
Please clarify.
BTW, here is a "road" schema:
Table: Road
-----------
roadID
roadTitle
roadType (Highway, Main, Side, Mixed, etc.)
Table: Points
-------------
pointID
Longit (longitude)
Lattit (lattitude)
Referential GPS resolution is about 30cm horizontally. Let's take, say, a
Germany map (not such a big country) with 30x30cm mesh... [Hint: roads have
limited width.]
There are other, perhaps better, ways to do this. I added a "Point"
table so intersection info may be easier to represent. This is just a
quickie demo.
.... of why this cannot work. Not to mention that GPS navigation system
calculates from a stream of longitude, latitude, height, mileage, speed
from the car, not only the road position, but relative positions of close
objects and the direction you are driving. All this is done with a high
level or error tolerance. GPS is very unreliable. Forgetting for a while,
that searching the DB you proposed would require several days (years?) per
query and a large truck to load the DB onto. Just write down a SELECT
statement for the model above!
One of the biggest selling points of RDBMS is that multiple languages
can use them.
You mean the languages, without which one couldn't be able to use these
RDBMS. I don't see how relying on concurrent products makes yours any
better...
Show with code.
But you said that you aren't interested in static program correctness
analysis.
If you want a challenge, fine. Take any machine learning method. Training
sets are ideal tables, rows and columns, nothing else. Take any method of
your choice and implement it in SQL! For introduction to existing methods,
see excellent tutorials by Andrew Moor:
http://www.autonlab.org/tutorials/
How about something from the domain of custom biz apps. I have already
conceded out of ignorance of the domain that DB's may not be good for
heavy-duty numerical analysis.
This is not numerical analysis. This a challenge to the relational approach
in general. There is a problem specified relationally, that has an obvious
relational solution, yet nobody would even try to use RDBMS for that. How
could THAT happen?
[ Answer: RDBMS are completely unsuitable either for matching in
multidimensional spaces, or for best-match criteria. The idea of separating
data and using normalized search schemas simply does not work beyond
trivial cases. Now, you will tell me that all biz-applications are trivial,
but I won't buy it. And for all I won't buy a tool limited to trivial
cases! ]
Again, I don't expect SQL or relational to solve the *entire* problem
by itself.
From this is derive that you consider relational is a niche solution for alimited number of problems. As such it cannot be a concurrent to OO.
But actually, they are incomparable not because relational is incomplete
and thus bad. It isn't bad. They are incomparable, because relational is of
lower level. You cannot compare a vehicle with a wheel, though a circus
rider could use the later. I, personally, better take a car. Some would a
jet or ship.
But to give an analogy, program code is merely data to the
interpreter/compiler.
I don't care about the CPU.
A developer may think of a function as
"behavior", but the interpreter treats it more like data if we look at
other processes that read what we normally call "data".
That the point, software is developed, maintained and finally scraped by
humans.
One thing is quite clear, it is impossible even to define the term "data",
without description of behavior. Look at mathematical definitions of
numbers.
"Data" is a set of computation states, characterized by definite behavior.
Perhaps you should make a distinction between "is a set of" and "can be
defined as a set of". Claiming something "is" is a strong ascertion.
For you, who believes in existence of data. To me, there is no data without
something that interprets them exposing a behavior. There is no information
without the receiver.
When it is said that a table cell contains 1, it means all states where Get
(or SELECT) would deliver result associated with the application domain
object denoted as 1.
It is the behavioral approach, which makes both OO and your beloved
relational model *implementation-independent*. Otherwise, you were unable
even to talk about "data", because, again, what in common have two states
of magnetic fields on the hard drives of two computers? They expose same
*behavior*, which you call "data"! Is big-endian and low-endian encoded
26732147 same "data"?
Perhaps, but that is an implemention issue. There may be other ways to
implement it.
Implement what? Again, there is no either data or implementation before you
fix some setup. Once I change the setup, implementation becomes rubbish and
data disappear. So the whole idea of extracting data is fundamentally
wrong. Note that true relational is a way of data *abstraction*, not
extraction (though on a lower level than ADT.) This is why I say that it
does not withstand OO. Data separation indeed does, but it is not
relational, it is just wrong.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- References:
- Prev by Date: Re: Factory or Inheritance for Initialisation?
- Next by Date: Re: Factory or Inheritance for Initialisation?
- Previous by thread: Re: SQL
- Next by thread: Re: SQL
- Index(es):
Relevant Pages
|
