XML is not a language, notwithstanding its own name. It's a metacodification, used to create codifications such as XQL, HTML, DocBook and so on.
OO people are usually programmers with very little CS fundamentals, so they don't even get this right: when they are talking about XML in database contexts, they should at least specify the coding they want to use. And then it should be understood that you need to use it for storage encoding, or for data communications, or both.
Thus one cannot say that XML was created for data interchange -- it was created for metacodification. One can create a data interchange codification based on XML -- but that's kind of stupid, since XML codifications usually will give big overheads. We've been doing data interchange with text files with little problems for years. The issue of agreeing on data model and codification between applications does not go away just because you agreed on using some codification with a big overhead.
But I haven't still touched on the worst on using XML codifications in database contexts -- it is that both XML and OO are hierarchical, thus a regression to thirty years ago when there were navigational databases, no data independence, hierarchical and network systems... we are throwing away thirty years of relational research without ever having implemented it right.
But that's the way of an uneducated world... just as people adopting proprietary technologies have thrown away open systems ideals without ever having got it right.
First thing, go educate yourselves, people! Start by reading "An Introduction to Database Systems", 7th ed (but any edition will be better than almost anything you can read about databases nowadays, be it printed or on the Web) by Chris J Date. After that, read anything you can get your hands on by Date, Hugh Darwen, Fabian Pascal, David McGoveran and EF Codd.
Second... the relational model for database management deals with the logical level of database management. It says nothing about physical storage. And normalization is a relational thing, so it has nothing to say about physical storage. Therefore, normalization does not help nor hinder performance, because performance depends on physical database design. It is perfectly feasible to have a database fully normalized, up to the 5th normal form, but still get great performance by using a good logical-to-physical mapping, with partitions, clusters and so on.
The real issue is that SQL does not separate properly the logical and physical levels, so that normalization may have an impact on the physical storage. But this isn't a normalization problem, it is a SQL defect.
So AMD will have the best x86 implementation ever, and 64 bits too... but what we need is to get rid of both x86 in favor of more efficient, smaller, cooler, RISC chips that use less energy and produce less heat, and of binary compatibility requirements by portable, preferrably free, software.
Because Intel is as technically incompetent and market strong-arming as Microsoft.
Alpha is faster. PowerPC is both faster and cooler (iBooks, iMacs and Cubes run cool without coolers!); both are 64 bits, or in the case of Power there are 64 bits versions in IBM servers. SPARC is faster, cooler, and an open standard.
Then why oh why we use Intel? One thing is how incompetent competitors have been. IBM couldn't market a PowerPC OS/2, nor create and open market around PowerPC. Sun got stuck in GUI and API Unix wars and never payed attention to mass marketing SPARC, be it by never releasing a port of NT, by not making Solaris user-friendly, by not backing GNU/Linux or by loosing the chance of GPL'ing Solaris arount 1.994. Digital lost the opportunity of having not only NT but also Novell Netware and Apple Mac OS running on Alpha -- not to mention the incredibly bad marketing of the superb duo, OpenVMS and Digital Unix.
Please please learn some Philosophy and throw in some Theology for good.
Values are absolute or they wouldn't be values, just opinions. Their application on the other hand is relative to circumstances and other, competing, values or to their objects.
For example, killing is bad. But killing to stop Hitler wasn't necessarily so, because besides the competing values of the German soldiers lives against the Jews and others' lives, you have thrown in the liberty and truth values.
Other example: lies are bad, but if you needed to lie to keep the Gestapo from finding your guest, a fleeing allied pilot or Jew, it starts looking better.
Or you could think that hurting someone or suicide is not good, but perhaps it's very good if it's done in order to keep your flight from crashing into the Capitol.
Only because values are absolute we can weight one against other in any given situation and make valid choices.
I posted almost the same thing as an AC by mistake, so here it goes again.
Case in point: MySQL. When database people dismiss MySQL, that's because the transactionless design of MySQL, besides putting your information at risk, betrays even the SQL name.
But that's not all. SQL in itself is a mistake, a contamination of the relational model. This is not the place to explain the relational model for database management, its conceptual and practical relevance, but you can find something more at http://dbdebunk.com./
The interesting thing here is that APL, under which Darwin is released, is actually less free than BSD, and even than GPL... yet a leading BSD proponent will work with Apple. That should give food for thought for those who have made the point that they despise GPL for being less free than BSD. --
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Not really so. An editor can be kicked out without a notice, and attempts to get a reason for it go unanswered. --
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
After having created and populated several categories they kicked me out of all of them, and suspended my editor account, without even a notice. Several attempts at getting a contact failed. And all the categories I created are now without an editor. Check, for instance, http://dmoz.org./Computers/Software/Databases/Rela tional and all subcategories; also http://dmoz.org./World/Português/Computadores has several subcategories created by me. --
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
SQL is crippling because it doesn't implements the
full relational model, as you can read in DBDebunk.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Competition isn't prosecution... Simon never claimed godhood, and anyway the problem wasn't competition itself, but that Simon tried to buy the apostles' power to perform miracles. --
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Don't throw away the baby with the water. The limitations of SQL
are due to it not supporting the full relational model, and to its
arbitrary limitations.
We need a properly implemented relational database language
-- probably based on Chris J
Date's and Hugh Darwen's The Third
Manifesto.
Going for any hierarchical model, be it an OODBMS or a filesystem
based one, is forfeiting all the relational model advantages because
you find SQL, which isn't really relational, lacking... and you get
nothing that any proper D wouldn't offer.
> Throughout history, cults have been branded as nefarious, predatory
> and corrupt. If one sits down and looks at the facts surrounding the
> critisims of Scientology and compares them to any of the major
> religions and the histories of those religions, the differences are
> obscured. Compare scientology to the preachers on BibleTV, and one
> finds little difference. Is it a scam, of course. However, freedom
I don't know BibleTV (I'm not from the US).
But Christians, once considered cult members
(Christianity was a Jewish sect), didn't kill dissenters, nor
prosecuted their opposers at their origins. This only began when the
Primitive Church became the official religion of the Roman Empire, the
decane pastors became bishops, and the bishop of Rome became the Pope,
thus making the Church, originally an organic, non-organized body,
into the Middle Ages' Roman Church. Even so, that was the European Middle
Ages. You can't compare that with US century XXI.
Your comparision lacks fundamenting facts, it is essentially an
expression of your own prejudices and lack of information.
> synical note, I'm in favor of things like Scientology in that they
> weed out (Darwin-effect) societies idiots. Its like the Judas-Priest
> albumn, or that MTV show that caused those kids to run themselves
> over. These things should be encouraged to rid our society of the Tom
> Cruises of the world.
Tell that to Nicole Kidman, who once obviously loved her
husband. Better yet, imagine a person you love gets in the hands of
Scientology. Would you love this person less because now you
classifies her as an idiot?
I believe Eazel couldn't succeed because their business model was actually a duplication of already existing functionality, especially their software catalogue Debian's dpkg.
While they could have created their own Debian distribution focusing on ease of use, enhanced Debian itself and made many things in the service space, they have chosen to duplicate much of the Debian infrastructure. But as Debian matures and GNU/Linux users learn that what they get paying for Eazel catalogue or Red Hat Network they can get for free from Debian, this business model dries, and not only for Eazel.
> relational databases will be around for a long time to
come
That is, whenever they arrive they will be around for a long
time. Up to now I know of no fully relational database or DBMS,
apart from BS12 and perhaps
Quel and Leap.
> it's clear that no automated solution exists that will
optimize performance in every case
Performance is not the only issue, not even the biggest one: data
access path independence and data integrity are bigger ones, and
more fundamental.
The problem is that up to this day no one fully implemented
relational theory in a modern system, nor proposed a better theory
than the relational one.
> It is interesting to see that a posting with so many wrong statements receives such a high rating here.
It seems that each of us have different ideas about what's right
and what's wrong, so let's get over such self-serving statements and
go over the issues at hand.
> Reality is object-oriented. We use objects in our modern
programming languages.
As far as I know reality may be represented by objects. It makes
no sense saying that reality is this or that oriented, since apart
from God no one can ever know what He was oriented to when he did
create.
Seriously, reality can be represented by objects. It can be
represented by relations also. Even if objects are convenient for
some programming domains, it isn't for data storage and retrieve,
except if your program will never change *and* it is
object-oriented. It's surprising to learn how many programming
gurus, and specially database gurus, steer clear of object-oriented
programming, rather keeping with other models of programming like the
functional or the structured ones.
> Why should we flatten these out to tables with unnecessary
keys...
Why should we complicate relations with objects, if we can store
data-independently?
Please, you are repeating OO jargon without explaining nothing to
me. As I never saw much sense in OOness, I will need better
teaching than this.
> Relations between objects can be maintained transparently
within the database.
This isn't the issue. The issue is that these relationships are
maintained physically in the database, thus getting against the
Information Principle. In contrast, relational databases have no
physical links. All relationships are a result of data kept in
common by different relations. I won't explain here what is a
relation; you should read Chris
J Date'sAn Introduction
to Database Systems for that.
> This is common-sense and there is no need to write
scientific papers about it.
It is common sense for uncommon OO programmers, not for DAs,
DBAs, functional or other non-OO programmers and common people
like me.
The fundamental issue of OO is that is an over-extension of some
simple programming rules-of-thumb. When they got the full extension
they have today they got much more complicated than the surprisingly
simple scientific papers that were published about relational
database model theory, like E F Codd's paper.
> You can design data by writing classes in your respective
programming language.
Not so fast. I want my data in my database, in a well defined
and theoretically sound *data* sublanguage, not only in a
programming language.
> [independence of the logical and physical layers of your database]
> Where do you need tables here?
> Class members define properties.
> Methods define behaviour.
If you want to compare relational databases to anything else, it
is better to think relations, not tables nor entities or
relationships.
Seriously again, relations are a logical representation. With
this logical representation of data at users' (and programmers')
hands, you can lay your data physically whatever way you want, even
by using pointers if you like. This way you can optimise the
physical layer for performance or availability or thoroughput or
whatever balance of whatever goals, while keeping data logically
organized, easily accessible and readily available to access plans
created by a good query optimizer.
> [shifting the performance optimization issues to the DBMS' optimizer]
> Object databases also use optimizers to analyze
queries.
But your access paths are predefined. The user has little
freedom to discover relationships between different data, ad
hoc queries will have weird access paths and little possibility
of optimization. And if you ever need a schema change, you will
have to rewrite lots of queries.
> [any schema change do not only need an application recompilation]
> There are object databases that manage schema versioning automatically.
> Our product simply stores a superset of all used schemas.
This won't fly. This is schema accumulation, not change. You
will have data stored in many different ways, and users will find
ways of wanting schema changes that can't be efficiently stored anyway.
> Wrong. Our object database is not multi-user as of
today
Then you haven't even faced the very issues relational theory was
created to solve. First read and understand
Codd's paper above, then we can talk. Write me
privately by email, or better yet read also The Third
Manifesto, then Database
Debunkings, and then we can talk.
> By the way: Do you typically have different tables for
different users?
Even in quasi-relational SQL each user has its own
schema. And this schema can contain base
relations, derived relations including named ones (views), and
synonyms.
> [rethink the data access path]
> Reengineering is a terrible problem with relational
databases.
I've been working for years with weak, quasi-relational SQL and
even with this poor tool I've not faced this problem of
"reengineering". I now you have a product to sell, so it may be hard
to forget marketspeak, even more actually acknowledging some fault,
but what do you mean really by reengineering? AFAIK this is a
management nineties' regurgitation of Operations and Methods ill
digested with some Data Processing thrown in, not a CS word.
> Strings are not typesafe, so you have to parse the entire
application
Stop! Stop! You're killing me!
Seriously, strings are strings. If SQL doesn't do all type checking it could,
it is no fault of strings per se, much less the relational
model. And it has no bearing in relational data independence. When
you change a data type, you have a different relation, there's no
way of shielding a typesafe language from that. Some data
sublanguage may provide some shortcuts to such modifications, and
even do some automatic type casting, but this is not a database
model issue.
> [which should give us practically all of the advantages of OODBMSs without their cons]
> We are going the other way. We want to provide all the
> relational functionality that you wish with
> our object database. We might finally end up
> with very similar engines.
Not at all, because you haven't yet understood the fundamentals
of the field.
> This is very much akin to having database schema for databases.
In fact there are many
people proposing to store
data as XML. I see a big danger here. Lots of people are encoding
data with XML to enable exchange, and that's OK. But when people
start thinking about storing that XML representation in a database,
they fail to realize all the benefits that a relational database
gives, both today with semi-relational
SQL and in the future with fully-relational
Tutorial D.
The issue is that OODBMSs do not conform neither to current database
best practices, nor to theory.
Relating to best practices, you should know already from other,
better-rated comments in this thread: you should design your data
before your application, OODBMSs make it hard; you should
strive for independence of the logical and physical layers of your
database, keeping data independence and shifting the performance
optimization issues to the DBMS' optimizer; OIDs hinder the
designation of candidate keys, of which the primary key is a special
case, and thus hinder a lot of data integrity checkings that should
be done by referential integrity. And we could go on and on.
As for the practical implications of not conforming to these best
practices, any schema change do not only need an application
recompilation, but also that you rethink the data access path (also
known as a query's access plan); you won't be able to keep several
logical schemas to different users, and the identity of the user's
view with the physical layout will force you to optimize only for
the most common case, instead of leaving it up to the DBMS to create
the best access plans.
All this is much better explained in
Database Debunkings, a site
co-maintained by Chris
J Date, author of the best database books I've ever read; you can
find a list of his available books also
there.
As for theory, there is no real substitute for the relational
database model theory. As Linus Torvalds thinks that
microkernels were a good idea but misguided, wielding no practical
nor theoretical improvements, so OODBMSs sounds nice but offer no
real improvements over RDBMSs. This is not to say that everything
you will ever need will be handled properly by your SQL DBMS. The
point is exactly that people have went for OODBMSs because they
thought that SQL was relational, and found it wanting. The problem
is that SQL never was truly relational, just an approximation of it.
Date has a whole book on it, called
The Third
Manifesto.
Summing up, what I am really trying to find is some proper
implementation of the relational database model ideals, which should
give us practically all of the advantages of OODBMSs without their
cons. I have just been informed of
Suneido, but have not investigated
it fully... it's a pity it is Win32, not POSIX.
The issue is a little bit thornier, and perhaps I'm a little bit stupidier than you think.
I'm married and have some responsibilities, and on the other hand I lack some basic training in Math such as Calculus and other High School syllabus. So what I think I really need is not a full undergraduate course, but a focused basic Math (including Calculus and all the High School stuff) and Logic tutorial that would enable me to learn programming and database theory. With this I would later be able pursue some job, be it commercial or academic, on databases.
I still haven't found anything like it, but would gladly be proved wrong.
Thank you for your attention, Glanz! --
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
You forget that the Romans didn't have the necessary cosmovision. The world to them was highly magic and tradition was far more important than advancements in knowledge.
The same was true of the ancient Chinese people, who invented lots of things and had far better navigation than Discovery Era Portuguese people, but lacked the motivation to use it effectively.
Even if the Greeks had a more rational mindset their culture was already decadent because of state-cities fighting each other, too much dependence on slave work and general decline of moral values. So the Romans conquered then and later failed too when they also went decadent, but then much knowledge was already lost.
As a side note, even if there was a bit of knowledge lost or severely restricted during the Dark (Middle) Age, the political agenda of Renaissance times that partially endures to this day keeps us from realizing that wise men even during the Dark Age knew a lot more than we usually suppose. For example, that the Earth is round was widely know by scholars of the time, it just wasn't accepted by the Tomist (Aristotelic) faction then dominant in the Roman Church that then dominated Western Europe.
It wasn't until Reformation and Renaissance that the world got the mindset necessary to foster widespread adoption of technological advancements and free communication of scientifical concepts.
Sad thing is that with copyright and patent laws misuse we might be going backwards in this mindset issue.
I want to leave my company because IT here is really really bad - Microsoft all over the place, including MS Exchange which prevents me from running GNU/Linux in my workstation, badly managed Unix servers, no quality standards, lots of people with no interest in technology whatsoever. The funny thing is that we dominate our marketing with a highly successfull... business computer program system!
Sometimes it is not so easy to leave... I have no formal Computer Science education, and I live at Brasil, so offers aren't abounding... what I really would like to do would go back to school, learn CS and get a master degree working towards a working implementation of Chris J Dates' Tutorial D relational database management system language, but I see no way of doing that. --
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
To have big fundings from the private sector is not necessarily a good idea. For one, CS courses are too "practical", that is, oriented to products, not to the fundamentals of the field. There are many courses in Universities that simply do not belong there, but are in the U. because of corporate funding.
Check the headline at http://web.mit.edu/newsoffice/nr/2001/ocw.html... it's against the "privatization of information". This implies that "information ought to be free", even if it was not necessarily the author's intention!
Slashdot Mirror
First one has to think about what's XML.
XML is not a language, notwithstanding its own name. It's a metacodification, used to create codifications such as XQL, HTML, DocBook and so on.
OO people are usually programmers with very little CS fundamentals, so they don't even get this right: when they are talking about XML in database contexts, they should at least specify the coding they want to use. And then it should be understood that you need to use it for storage encoding, or for data communications, or both.
Thus one cannot say that XML was created for data interchange -- it was created for metacodification. One can create a data interchange codification based on XML -- but that's kind of stupid, since XML codifications usually will give big overheads. We've been doing data interchange with text files with little problems for years. The issue of agreeing on data model and codification between applications does not go away just because you agreed on using some codification with a big overhead.
But I haven't still touched on the worst on using XML codifications in database contexts -- it is that both XML and OO are hierarchical, thus a regression to thirty years ago when there were navigational databases, no data independence, hierarchical and network systems... we are throwing away thirty years of relational research without ever having implemented it right.
But that's the way of an uneducated world... just as people adopting proprietary technologies have thrown away open systems ideals without ever having got it right.
--
First thing, go educate yourselves, people! Start by reading "An Introduction to Database Systems", 7th ed (but any edition will be better than almost anything you can read about databases nowadays, be it printed or on the Web) by Chris J Date. After that, read anything you can get your hands on by Date, Hugh Darwen, Fabian Pascal, David McGoveran and EF Codd.
Second... the relational model for database management deals with the logical level of database management. It says nothing about physical storage. And normalization is a relational thing, so it has nothing to say about physical storage. Therefore, normalization does not help nor hinder performance, because performance depends on physical database design. It is perfectly feasible to have a database fully normalized, up to the 5th normal form, but still get great performance by using a good logical-to-physical mapping, with partitions, clusters and so on.
The real issue is that SQL does not separate properly the logical and physical levels, so that normalization may have an impact on the physical storage. But this isn't a normalization problem, it is a SQL defect.
So AMD will have the best x86 implementation ever, and 64 bits too... but what we need is to get rid of both x86 in favor of more efficient, smaller, cooler, RISC chips that use less energy and produce less heat, and of binary compatibility requirements by portable, preferrably free, software.
Because Intel is as technically incompetent and market strong-arming as Microsoft.
Alpha is faster. PowerPC is both faster and cooler (iBooks, iMacs and Cubes run cool without coolers!); both are 64 bits, or in the case of Power there are 64 bits versions in IBM servers. SPARC is faster, cooler, and an open standard.
Then why oh why we use Intel? One thing is how incompetent competitors have been. IBM couldn't market a PowerPC OS/2, nor create and open market around PowerPC. Sun got stuck in GUI and API Unix wars and never payed attention to mass marketing SPARC, be it by never releasing a port of NT, by not making Solaris user-friendly, by not backing GNU/Linux or by loosing the chance of GPL'ing Solaris arount 1.994. Digital lost the opportunity of having not only NT but also Novell Netware and Apple Mac OS running on Alpha -- not to mention the incredibly bad marketing of the superb duo, OpenVMS and Digital Unix.
Please please learn some Philosophy and throw in some Theology for good.
Values are absolute or they wouldn't be values, just opinions. Their application on the other hand is relative to circumstances and other, competing, values or to their objects.
For example, killing is bad. But killing to stop Hitler wasn't necessarily so, because besides the competing values of the German soldiers lives against the Jews and others' lives, you have thrown in the liberty and truth values.
Other example: lies are bad, but if you needed to lie to keep the Gestapo from finding your guest, a fleeing allied pilot or Jew, it starts looking better.
Or you could think that hurting someone or suicide is not good, but perhaps it's very good if it's done in order to keep your flight from crashing into the Capitol.
Only because values are absolute we can weight one against other in any given situation and make valid choices.
I posted almost the same thing as an AC by mistake, so here it goes again.
Case in point: MySQL. When database people dismiss MySQL, that's because the transactionless design of MySQL, besides putting your information at risk, betrays even the SQL name.
But that's not all. SQL in itself is a mistake, a contamination of the relational model. This is not the place to explain the relational model for database management, its conceptual and practical relevance, but you can find something more at http://dbdebunk.com./
The interesting thing here is that APL, under which Darwin is released, is actually less free than BSD, and even than GPL... yet a leading BSD proponent will work with Apple. That should give food for thought for those who have made the point that they despise GPL for being less free than BSD.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Not really so. An editor can be kicked out without a notice, and attempts to get a reason for it go unanswered.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
After having created and populated several categories they kicked me out of all of them, and suspended my editor account, without even a notice. Several attempts at getting a contact failed. And all the categories I created are now without an editor. Check, for instance, http://dmoz.org./Computers/Software/Databases/Rela tional and all subcategories; also http://dmoz.org./World/Português/Computadores has several subcategories created by me.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
SQL is crippling because it doesn't implements the full relational model, as you can read in DBDebunk.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Competition isn't prosecution... Simon never claimed godhood, and anyway the problem wasn't competition itself, but that Simon tried to buy the apostles' power to perform miracles.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Don't throw away the baby with the water. The limitations of SQL are due to it not supporting the full relational model, and to its arbitrary limitations.
We need a properly implemented relational database language -- probably based on Chris J Date's and Hugh Darwen's The Third Manifesto.
Going for any hierarchical model, be it an OODBMS or a filesystem based one, is forfeiting all the relational model advantages because you find SQL, which isn't really relational, lacking... and you get nothing that any proper D wouldn't offer.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
> Throughout history, cults have been branded as nefarious, predatory > and corrupt. If one sits down and looks at the facts surrounding the > critisims of Scientology and compares them to any of the major > religions and the histories of those religions, the differences are > obscured. Compare scientology to the preachers on BibleTV, and one > finds little difference. Is it a scam, of course. However, freedom
I don't know BibleTV (I'm not from the US).
But Christians, once considered cult members (Christianity was a Jewish sect), didn't kill dissenters, nor prosecuted their opposers at their origins. This only began when the Primitive Church became the official religion of the Roman Empire, the decane pastors became bishops, and the bishop of Rome became the Pope, thus making the Church, originally an organic, non-organized body, into the Middle Ages' Roman Church. Even so, that was the European Middle Ages. You can't compare that with US century XXI.
Your comparision lacks fundamenting facts, it is essentially an expression of your own prejudices and lack of information.
> synical note, I'm in favor of things like Scientology in that they > weed out (Darwin-effect) societies idiots. Its like the Judas-Priest > albumn, or that MTV show that caused those kids to run themselves > over. These things should be encouraged to rid our society of the Tom > Cruises of the world.
Tell that to Nicole Kidman, who once obviously loved her husband. Better yet, imagine a person you love gets in the hands of Scientology. Would you love this person less because now you classifies her as an idiot?
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
I believe Eazel couldn't succeed because their business model was actually a duplication of already existing functionality, especially their software catalogue Debian's dpkg.
While they could have created their own Debian distribution focusing on ease of use, enhanced Debian itself and made many things in the service space, they have chosen to duplicate much of the Debian infrastructure. But as Debian matures and GNU/Linux users learn that what they get paying for Eazel catalogue or Red Hat Network they can get for free from Debian, this business model dries, and not only for Eazel.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
> relational databases will be around for a long time to come
That is, whenever they arrive they will be around for a long time. Up to now I know of no fully relational database or DBMS, apart from BS12 and perhaps Quel and Leap.
> it's clear that no automated solution exists that will optimize performance in every case
Performance is not the only issue, not even the biggest one: data access path independence and data integrity are bigger ones, and more fundamental.
The problem is that up to this day no one fully implemented relational theory in a modern system, nor proposed a better theory than the relational one.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
> It is interesting to see that a posting with so many wrong statements receives such a high rating here.
It seems that each of us have different ideas about what's right and what's wrong, so let's get over such self-serving statements and go over the issues at hand.
> Reality is object-oriented. We use objects in our modern programming languages.
As far as I know reality may be represented by objects. It makes no sense saying that reality is this or that oriented, since apart from God no one can ever know what He was oriented to when he did create.
Seriously, reality can be represented by objects. It can be represented by relations also. Even if objects are convenient for some programming domains, it isn't for data storage and retrieve, except if your program will never change *and* it is object-oriented. It's surprising to learn how many programming gurus, and specially database gurus, steer clear of object-oriented programming, rather keeping with other models of programming like the functional or the structured ones.
> Why should we flatten these out to tables with unnecessary keys...
Why should we complicate relations with objects, if we can store data-independently?
Please, you are repeating OO jargon without explaining nothing to me. As I never saw much sense in OOness, I will need better teaching than this.
> Relations between objects can be maintained transparently within the database.
This isn't the issue. The issue is that these relationships are maintained physically in the database, thus getting against the Information Principle. In contrast, relational databases have no physical links. All relationships are a result of data kept in common by different relations. I won't explain here what is a relation; you should read Chris J Date's An Introduction to Database Systems for that.
> This is common-sense and there is no need to write scientific papers about it.
It is common sense for uncommon OO programmers, not for DAs, DBAs, functional or other non-OO programmers and common people like me.
The fundamental issue of OO is that is an over-extension of some simple programming rules-of-thumb. When they got the full extension they have today they got much more complicated than the surprisingly simple scientific papers that were published about relational database model theory, like E F Codd's paper.
> You can design data by writing classes in your respective programming language.
Not so fast. I want my data in my database, in a well defined and theoretically sound *data* sublanguage, not only in a programming language.
> [independence of the logical and physical layers of your database]
> Where do you need tables here?
> Class members define properties.
> Methods define behaviour.
If you want to compare relational databases to anything else, it is better to think relations, not tables nor entities or relationships.
Seriously again, relations are a logical representation. With this logical representation of data at users' (and programmers') hands, you can lay your data physically whatever way you want, even by using pointers if you like. This way you can optimise the physical layer for performance or availability or thoroughput or whatever balance of whatever goals, while keeping data logically organized, easily accessible and readily available to access plans created by a good query optimizer.
> [shifting the performance optimization issues to the DBMS' optimizer]
> Object databases also use optimizers to analyze queries.
But your access paths are predefined. The user has little freedom to discover relationships between different data, ad hoc queries will have weird access paths and little possibility of optimization. And if you ever need a schema change, you will have to rewrite lots of queries.
> [any schema change do not only need an application recompilation]
> There are object databases that manage schema versioning automatically.
> Our product simply stores a superset of all used schemas.
This won't fly. This is schema accumulation, not change. You will have data stored in many different ways, and users will find ways of wanting schema changes that can't be efficiently stored anyway.
> Wrong. Our object database is not multi-user as of today
Then you haven't even faced the very issues relational theory was created to solve. First read and understand Codd's paper above, then we can talk. Write me privately by email, or better yet read also The Third Manifesto, then Database Debunkings, and then we can talk.
> By the way: Do you typically have different tables for different users?
Even in quasi-relational SQL each user has its own schema. And this schema can contain base relations, derived relations including named ones (views), and synonyms.
> [rethink the data access path]
> Reengineering is a terrible problem with relational databases.
I've been working for years with weak, quasi-relational SQL and even with this poor tool I've not faced this problem of "reengineering". I now you have a product to sell, so it may be hard to forget marketspeak, even more actually acknowledging some fault, but what do you mean really by reengineering? AFAIK this is a management nineties' regurgitation of Operations and Methods ill digested with some Data Processing thrown in, not a CS word.
> Strings are not typesafe, so you have to parse the entire application
Stop! Stop! You're killing me!
Seriously, strings are strings. If SQL doesn't do all type checking it could, it is no fault of strings per se, much less the relational model. And it has no bearing in relational data independence. When you change a data type, you have a different relation, there's no way of shielding a typesafe language from that. Some data sublanguage may provide some shortcuts to such modifications, and even do some automatic type casting, but this is not a database model issue.
> [which should give us practically all of the advantages of OODBMSs without their cons]
> We are going the other way. We want to provide all the
> relational functionality that you wish with
> our object database. We might finally end up
> with very similar engines.
Not at all, because you haven't yet understood the fundamentals of the field.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
> If you store your data by maintenance method
I don't really know what you mean.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
> This is very much akin to having database schema for databases.
In fact there are many people proposing to store data as XML. I see a big danger here. Lots of people are encoding data with XML to enable exchange, and that's OK. But when people start thinking about storing that XML representation in a database, they fail to realize all the benefits that a relational database gives, both today with semi-relational SQL and in the future with fully-relational Tutorial D.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
The issue is that OODBMSs do not conform neither to current database best practices, nor to theory.
Relating to best practices, you should know already from other, better-rated comments in this thread: you should design your data before your application, OODBMSs make it hard; you should strive for independence of the logical and physical layers of your database, keeping data independence and shifting the performance optimization issues to the DBMS' optimizer; OIDs hinder the designation of candidate keys, of which the primary key is a special case, and thus hinder a lot of data integrity checkings that should be done by referential integrity. And we could go on and on.
As for the practical implications of not conforming to these best practices, any schema change do not only need an application recompilation, but also that you rethink the data access path (also known as a query's access plan); you won't be able to keep several logical schemas to different users, and the identity of the user's view with the physical layout will force you to optimize only for the most common case, instead of leaving it up to the DBMS to create the best access plans.
All this is much better explained in Database Debunkings, a site co-maintained by Chris J Date, author of the best database books I've ever read; you can find a list of his available books also there.
As for theory, there is no real substitute for the relational database model theory. As Linus Torvalds thinks that microkernels were a good idea but misguided, wielding no practical nor theoretical improvements, so OODBMSs sounds nice but offer no real improvements over RDBMSs. This is not to say that everything you will ever need will be handled properly by your SQL DBMS. The point is exactly that people have went for OODBMSs because they thought that SQL was relational, and found it wanting. The problem is that SQL never was truly relational, just an approximation of it. Date has a whole book on it, called The Third Manifesto.
Summing up, what I am really trying to find is some proper implementation of the relational database model ideals, which should give us practically all of the advantages of OODBMSs without their cons. I have just been informed of Suneido, but have not investigated it fully... it's a pity it is Win32, not POSIX.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
I would be very, very grateful, thanks in advance!
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
The issue is a little bit thornier, and perhaps I'm a little bit stupidier than you think.
I'm married and have some responsibilities, and on the other hand I lack some basic training in Math such as Calculus and other High School syllabus. So what I think I really need is not a full undergraduate course, but a focused basic Math (including Calculus and all the High School stuff) and Logic tutorial that would enable me to learn programming and database theory. With this I would later be able pursue some job, be it commercial or academic, on databases.
I still haven't found anything like it, but would gladly be proved wrong.
Thank you for your attention, Glanz!
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
You forget that the Romans didn't have the necessary cosmovision. The world to them was highly magic and tradition was far more important than advancements in knowledge.
The same was true of the ancient Chinese people, who invented lots of things and had far better navigation than Discovery Era Portuguese people, but lacked the motivation to use it effectively.
Even if the Greeks had a more rational mindset their culture was already decadent because of state-cities fighting each other, too much dependence on slave work and general decline of moral values. So the Romans conquered then and later failed too when they also went decadent, but then much knowledge was already lost.
As a side note, even if there was a bit of knowledge lost or severely restricted during the Dark (Middle) Age, the political agenda of Renaissance times that partially endures to this day keeps us from realizing that wise men even during the Dark Age knew a lot more than we usually suppose. For example, that the Earth is round was widely know by scholars of the time, it just wasn't accepted by the Tomist (Aristotelic) faction then dominant in the Roman Church that then dominated Western Europe.
It wasn't until Reformation and Renaissance that the world got the mindset necessary to foster widespread adoption of technological advancements and free communication of scientifical concepts.
Sad thing is that with copyright and patent laws misuse we might be going backwards in this mindset issue.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
I want to leave my company because IT here is really really bad - Microsoft all over the place, including MS Exchange which prevents me from running GNU/Linux in my workstation, badly managed Unix servers, no quality standards, lots of people with no interest in technology whatsoever. The funny thing is that we dominate our marketing with a highly successfull... business computer program system!
Sometimes it is not so easy to leave... I have no formal Computer Science education, and I live at Brasil, so offers aren't abounding... what I really would like to do would go back to school, learn CS and get a master degree working towards a working implementation of Chris J Dates' Tutorial D relational database management system language, but I see no way of doing that.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
To have big fundings from the private sector is not necessarily a good idea. For one, CS courses are too "practical", that is, oriented to products, not to the fundamentals of the field. There are many courses in Universities that simply do not belong there, but are in the U. because of corporate funding.
I suggest reading Skyscrapers with Shack Foundations, by Fabian Pascal, and Edsger Dijkstra's Convocation Speech at Univ of Texas at Austin.
--
Leandro Guimarães Faria Corcete Dutra
DBA, SysAdmin
Check the headline at http://web.mit.edu/newsoffice/nr/2001/ocw.html... it's against the "privatization of information". This implies that "information ought to be free", even if it was not necessarily the author's intention!
--
Leandro Guimarães Faria Corcete Dutra
DBA, SysAdmin