Re: SQL


Dmitry A. Kazakov wrote:
On 7 Feb 2006 18:04:08 -0800, topmind wrote:

Dmitry A. Kazakov wrote:
On 6 Feb 2006 19:32:11 -0800, topmind wrote:

The context was "configurable" integers. You are using the
out-of-the-box 8-byte version here, not configurable ones.

Replace the first line with:

type I is range -223452345..234234234;

That is a language-specific feature.


Now show me a relational equivalent!

"Cell types" are generally orthogonal to the relational model.
Relational only cares that the "expression engine" follow a minimum set
of rules, as already described. Thus, your question is outside of
relational.

You need a table of types. In that
table you need columns for minimal and maximal values, set to NULL when not
applicable. You need a column describing the class of the type [numberic,
string etc] and the operations defined on it. A type will be created by an
INSERT statement etc. Cool! (:-))

Sounds like a Data Dictionary. A nice feature, but not necessary for
"relational", as described above.


Rounding errors for "add"?

Add 1.0 to 1000000000.0 in IEEE 32-bit and print the result. That should be
the very first thing students should do in classes. This is why different
numeric models exist. There is a trade-off space, performance, accuracy,
set of closed operations. It isn't rocket science...

That is only for pretty large numbers. Usually a dedicated decimal
library is used or they only allow COBOL for such calculations, because
it has "money-friendly" constructs already built in. (Most big-money
financial software is still COBOL, for good or bad.)

Further, most commercial RDBMS have a "money" or "decimal" type such
that one does not have to use floating.


Floating point tends to stink for biz apps,

Rubbish. What stinks is lack of understanding differences between numeric
models and missing contracts specifying the *semantics* of numeric
operations.

How would putting a wrapper around them fix the above problem you
mention? At best it could only report that the inputs are too large to
guarentee the right answer. If you go beyond the size of Double, then
you have gone beyond. That's that. Either you use a different number
model or you are hosed.


Why are you selecting "science lab" kinds of problems anyhow?

1. There is no such division. When a customer comes to us, he asks for a
complete solution of his problem. That includes data acquisition, data
archiving, human-machine interface, and a bit of "science lab."

Here is a ROUGH general breakdown of domains as I perceive the IT
world:

30% custom biz apps (90% RDBMS included/used)
15% packaged biz apps (70% RDBMS included/used)
15% embedded apps (less than 10% RDBMS)
10% factory/process control (40% RDBMS included/used)
10% scientific/math apps (25% RDBMS included/used)
10% entertainment apps (15% RDMBS included/used)
10% other (est. 30% RDBMS included/used)


2. It is a paradigm in question. A paradigm should be capable to decompose
any problem.


I disagree with such a definition! I buy into Yin-Yang *complimentary*
use of *multiple* tools. One-size-fits-all is old-style and multi-tool
usage is on the increase.



Can I copy it? Is the
copy unique again? In which scope? Can I add such keys? Sort them? These
questions have many contradicting answers. Sometimes I need one answer,
sometimes other. ADT solves that by having clear contracts of the objects
in use.

Show me! OO has a horrible time with usable identity, with no built-in
referential tools whatsoever, leading to "creative" solutions.

OO gives you an opportunity to analyse the problem. It does not warranty,
that you'll find a solution. The point I'm trying to make that you cannot
freeze types, it must be an open-end types system. Your position is that
openness stops with data. This is too limiting.

Show me relational being limiting to my domain.

Yes. It means that your model isn't complete.

"Complete" for what?

For efficient software reuse.

Reuse? This is a new bash against relational (IIRC). Example?


Note also relations, as found
in mathematics, do not impose any such limitations. I can have a set of
sets, a set of set of sets, etc and define relations on them.

So? You can also nest a mess inside a mess inside a mess inside a mess.
However, please keep it out of our world.

Then, please, don't argue to the authority of mathematics. It isn't on your
side.

I have surrenderred math-intensive apps multiple times due to my lack
of experience there. I am running out of white flags for that niche.


Relational imposes rules to be called "relational". Otherwise, it would
turn into the navigational messes that motivated the creation of
relational to begin with.

So data in RDBs cannot be properly structured. Fortunately there still
exist hierarchical DBs!

"Properly"? As defined by what?

By the application domain. Relational approach forces quite artificial
constructions.

I don't see them. In fact, relational is pretty good where the domain
*is* artificial, such as dealing with intellectual ideas such as
invoices, intellectual property, marketing rules, etc. Modelling the
Cartesion coordinate (X,Y,Z) physical world is perhaps where it does
not do so well.


No, we wish to model them as relations! Polygon isn't a relation. You can
have a table of rows representing polygons, that's OK. Now, write the
SELECT statement that gives me the car position, movement direction and
distance to the next turn I have to do. Show, how this problem can be
decomposed using relational approach.

Use the distance formula to find the nearest matches. The rest is left
as a reader excercise.

No that will extract the whole table and sort it by the distance! Many
thanks!

...And Distance < myThreashold

Most SQL dielects also let one limit the number of rows returned. (Some
argue that is not part of relational, but it can be considered a common
database service. A.C.I.D. Transactions and sorting are also not part
of relational, but are a common service supplied by DBs, even
non-relational ones.)

[pixel example]

Relational does not dictate implementation. Yes, it means you may have
to have custom programmed RDBMS engines to get the most compact
representation possible, but that will be the case no matter what you
use.

Stop here. "Custom" in "custom programmed RDBMS engine" means
non-relationally programmed. Am I right?

Heck no! A custom made/tuned relational engine is certainly as possible
as making a non-relational one. A non-trivial commercial graphics
engine will almost certain be custom-built for graphics regardless of
paradigm used.


--
Regards,
Dmitry A. Kazakov

-T-

.

Relevant Pages

  • Re: What is the migration process?
    ... > - custom files to retain ... > even list which apps you better darned well retain the installer for. ... > Deauthorize iTunes and Adobe products. ...
    (comp.sys.mac.advocacy)
  • Re: What is the migration process?
    ... - custom files to retain ... I print my application database (a FileMaker database of all my apps, ... even list which apps you better darned well retain the installer for. ... Deauthorize iTunes and Adobe products. ...
    (comp.sys.mac.advocacy)
  • Re: Why do IT guys hate MS Access?
    ... created databases being a mess". ... > for fairly complex production apps when it's managed properly by pros. ... Our division policy is that the *user* is totally ...
    (comp.databases.ms-access)
  • Re: WinXP performance, diagnostic and optimization software
    ... What I do in my business is, among other things, design ... custom user and database apps that interface to commercial business software ... such util but I do not trust it; it finds supposed unused DLLs but it ...
    (microsoft.public.windowsxp.general)
  • Re: Upgrading to AMD 64
    ... the only problem you may encounter is with the mess that ... > found that when I compiled mono (and a few other apps), ...
    (uk.comp.os.linux)