>
No, an ad hominem argument would be:
"You are a jerk."
Actually that would be either an insult, or an statement of fact, or both, but not an argument. To be an ad hominem argument you would have to say one is wrong because one is a jerk.
Now, you certainly did not insult me, but you in fact said I was incurring in the same error I identified in others, and that by virtue of my profession. That is what an ad hominem argument is.
And thus you avoided analysing the point I had made. That is what an ad hominem argument is for.
>
No-one would dare suggest that XML is a way of
storing data.
Incredible as it may seem, that is not true... there is lots of
misguided talk about XML databases and DBMSs.
>
XML is a way of sharing information, not
storage.
XML is text markup for human-machine interface, only that. Now the
distinction you are making between sharing and storage is not clear
enough.
There are actually three levels in data storage and representation:
the physical, the logical and the user levels. The relational model
is concerned with the logical and the user levels; the physical level
is (should be) under the hood only, for DBAs, SysAdmins, system
programmers and the like, not for application programmers and
users.
Now, what is the difference between information sharing
(communication) and the user level representation? None. What does
XML adds to the relational model? Nothing, apart from overhead,
restrictions & complexity. What does it substract? Simplicity,
power, expressiveness, logical foundations & performance.
>
I certainly don't agree that data _must_ _be_ in a
relational database to make it available to
computers.
Well, it depends on your goals. If one wants to burn CPU cycles,
waste storage, limit usage, employ armies of programmers, and
generally deny access and power to the users, then one must not use
relational systems indeed.
>
Why limit data expression only to those realms that
can be expressed in a tabular fashion?
Ah, now I see where you are getting lost. You are identifying SQL
with relational, and that is Simply Not True. SQL is indeed full of
arbitrary restrictions, but that comes because it violates
the relational model. If it had followed the relational model, it
would be truly general.
In fact, there is no other data model that can provide general
enough access to all kinds of data. All the other technologies are
too low-level, and thus application-specific.
>
Your subject, and your refutation of it certainly
strikes me as a case of Mr Pot calling Mr Kettle
black.
Could you make your case more objectively? I am sure I did not
understood the idiom you used.
Re:Linux games vs. shareware stuff for Win
on
25 Best Linux Games
·
· Score: 1
>
I've never found freely available Windows game that would be fun.
I am not a gamer by any means, but shareware Terminal Velocity was very good. It was not a MS-W32 game, but one of those that included its own operating system -- TVOS -- and drivers, to be loaded by (MS|DR|PC)-DOS.
It was so good that MS bought it, ported it to MS-W32, renamed it to Hellbender or something the like, retracted the DOS version and erased nearly all references to it from the Net.
>
permit copyrights 50 years after the death of the author while (as we know) the US is now twice that.
Do we know indeed? I think the US is 70 years.
By the way, copy rights aren't permitted, they are granted. Copy rights are not a natural rights permission, but a state-enforced artificial monopoly grant.
...everything looks like a nail.
XML is text markup, it is not a generic data model.
If one wants to make data available to computers, data must be in an accessible relational database system under an agreed-upon, domain-specific data model.
>
Essential for what? Doing real world work or fitting Codd's list? While a nice feature, lacking it does not fully disqualify a DBMS from being a DBMS.
You can never scale, nor even be sure of your data integrity, without transaction. Fact. Period. If you do not understand that, you do not understand data. You might still manage to get some thing done, but with tremendous inefficiency, risk and limitations.
>
about 99% of our well-written SQL statements converted from DB2 to MySQL without changing
The question is not how well-written are the statements. But how well modelled is the database. A normalised database enables users to do much more intelligent queries. And most people code well in the sense that the statements are not ugly, but very bad indeed in failing to make use of the integrity constraints available in SQL, thus duplicating effort, wasting resources and risking data.
>
Yes, MySQL is missing many obscure features, but in my opinion, most of what it is missing shouldn't have been included in SQL in the first place. It has SELECT, UPDATE, and INSERT. There isn't much else considered essential to SQL.
Pointers and NULLs, or GROUP BY sure enough should never had been included. But integrity constraint and transactions are hardly obscure, but truly essential. If you do not see that, you never understood SQL.
>
The InnoDB hack and the DBD hack, while interesting, isn't useful for a production system.
I agree they are a hack, and discount MySQL also on that basis. But all I heard of InnoDB is that it is an amazing piece of software, and that is is badly integrated but this impacts development (never forget specifying the table type), not operation. Why do you think it cannot be used in production?
>
MySQL has all of the standard data types. A bunch of different integer sizes, numeric, floating point, characters, dates, etc.. No, it doesn't have many of the off the wall data types the PostgreSQL has (latitude and longitude? IP addrs? polar coordinates? RGB?), but for those of us that want a standard SQL server without the bloat, that's a good thing.
First, let me admit that I just checked and MySQL does now have a decent basic SQL type system. But reading their documentation really drove me nuts: they still think of tables as the basic construct, and generally do not grok databases except as as programming utility. Treating transactions as optional... hah!
Not only that, but their comparision with PostgreSQL is really biased, more than is granted in vendor-written material. If they cannot be a little bit fairer, they should refrain from speech.
Now, I do not think PostgreSQL to be bloated. Evidence to the contrary welcome.
And if there is something that PostgreSQL does right, is in an extensible type system. MySQL does not plan to implement the single redeeming SQL feature!
>
In what way does it treat transactions improperly?
Transactions are only supported in the optional table type InnoDB. Now, even the notion of an optional table type is unnecessary complexity: transactions must be the default behaviour. Not even PostgreSQL gets this as well as I would hope, but MySQL really is a mess. Now InnoDB is an amazing piece of software, but it needs to be the default, standard, do-not-even-think-about-it thing to do.
>
Which are? What standard(s) are you comparing against?
What about ISO SQL? Take anything from SQL 89 Entry Level, MySQL compliance is as bad as Oracle and even worse, without its robustness.
>
You *seem* to be saying that because they're adding new bits and pieces on seemingly randomly the language isn't SQL?
No, I mean that the language is not SQL, and there is not a clear direction about if and when it will reach compliance, and with which caveats.
>
The term arose before relational was born I believe
One can argue that only a relational system can be a better DBMS, but sure there were and are non-relational DBMSs, for example SQL.
>
perhaps before transactional integrity. (We would have to check the history books.)
Yet nowadays data integrity is inherent part of a DBMS. Same as with OSs: initial ones would be little but loaders nowadays; today if someone launched a CP/M thingie it would never be accepted as a OS. The threshold shifts.
>
Postgre does not have the acceptence-level that MySQL does.
And? It does not make MySQL any better, same as the wider availability of MS-WXP does not make it any better.
>
If Chris Date wants to get his ideas more widely accepted, I suggest he start an open-source movement. Nobody is going to pay for something "weird", but they like to play with such if they don't have to fork over greenbacks.
Agreed, and I already told them so. I even tried to start a SourceForge project, but my time is not yet ripe. Anyway there is Alphora Dataphor already, which is not free in any meaning but has a free, feature-full demo available. And anyone can implement either Tutorial D, or D4, or any other valid D.
>
If it's not, I'd like you to prove me wrong since it's does infact--manage my data for me.
You have to do the integrity control, it doesn't yet. It is beginning to with InnoDB, but in a non-integrated, incomplete manner that needs an extra mile from you. So you can say it's not so good as it could be, but I would say it's not the real thing at all. Admittedly, no SQL flavour is or can be perfect, and no implementation of SQL is complete, but there are file access libraries, there are DBMSs, and things in between. MySQL is in between as yet.
>
How is requiring less requiring to much? Is this some kind of doublethink? I had a quick look over a begginers guide to Oracle and PHP, the amount of code for a connection or query was more complicated than MySQL. Now if the application doesn't need anything more complex than MySQL. What the point in going with anything else?
Being scalable, generic, and declarative. MySQL may require less to start, but it sure requires more to develop and to scale.
If one starts with MySQL, eventually he will discover he needs something better. Then he will have to migrate, and in addition to the migration pain itself he will discover in horror that he could have done in a few declarative SQL integrity constraint lines what took lots of complex, error-prone procedural applicative code when using MySQL.
Now Oracle and PHP is not a good combination. PHP is not good with databases at all. And Oracle is know to be too complex and not conformant to anything but SQL Entry Level. But at least some of Oracle's complexity comes from it being scalable: you can connect to any account in any instance, but you never need more than a username/password@instance once your tnsnames.ora is set.
>
it isn't a real SQL DBMS either. But it still uses a lot of it's language--It supports a subset of MySQL. And like I said before, if that all that's needed, why bother with something else?
Because something else will require less coding and help you preserve your data integrity better, as well as scaling better.
See you still did not do your homework, Tablizer...
>
Transaction management is not necessarily a prerequisite for "database" (DBMS). There is no cononical definition of "database" (DBMS).
First, you have to decide what you are talking about, a database or a DBMS. Putting quotes around a database does not make it a DBMS, which is quite a different thing.
Second, a DBMS is a system to manage data. Keep its integrity, allow for perfoming backup, control and enable access and manipulation. So transactions are a part of what a DBMS is supposed to do. If one dillutes a concept to include X, X is happy, but the word becames useless.
>
the Inno extensions for transactions are not that hard to install, are they?
Perhaps not, and actually InnoDB is quite good in itself. But yet it does not solve all MySQL problems, while simply using PostgreSQL does.
>
SQL is what there is for the average programmer. Yes, it is an imperfect standard, but at least there is a standard.
Then why use MySQL, which fails to implement it?
>
I don't know of any decent open-source "true" relational DBMS's anyhow. Unlike OSS "true" relational products, at least MySQL exists.
Freedom (source code openness somehow is not euphonic enough) is orthogonal to the relational model and to the SQL standard. If freedom is essential and SQL acceptable, PostgreSQL fits the bill much better. If not, then we do have Alphora Dataphor. It is a tough choice, but luckily we are not bound to suffer MySQL.
>
that means that Oracle or DB2 or MSSQL or PostGreSQL aren't databases if they have no data in them, and that my even asshole can be a database if I shove a small collection of data up it.
No, that means that a database is not a DBMS, and that a DBMS is not a database. See, a DBMS is a database management system, therefore it cannot be the thing it was created to manage. Similarly, data does not manage itself, but needs a DBMS (or a SysAdmin, operator or whatever else) to do that.
>
it's still a god damn database in reality, and according to your own deffinition.
According to my definition it tries to be a DBMS, but fails for requiring too much of users and programmers. And it fails to be a SQL system too. But it sure can be used to suboptimally access a database.
But to cut a long story short, SQL does not support relational prescriptions as data independence (SQL views are not consistently updateable), nor respect relational proscriptions (undifferentiated NULLs), nor abide by the fundamental relational principles (pointers violate the Information Principle, OO extensions mess the simple domain, attribute, tuple, relation that is central to the relational model).
>
on Mysql, precisely?
Its language is not proper SQL at all: it does not support transactions properly, nor has the necessary data types, and has been adding features kinda haphazardly without neither admitting to past mistakes nor presenting a clear roadmap to either SQL or the relational model. It should be called PseudoSQL, or SubSQL, or SimplerThanSQL.
Not quite. TP monitors aren't message-oriented. But they are still a pretty fundamental piece of software for many applications that hasn't yet being implemented as free software.
>
Think about it, in real life, when you borrow a book from your local library, you have to bring it back. This is for the simple reason that other people can read it too. If you don't bring it back, you have to buy a copy for the library to replace it. Of course we don't have the same problem here, but without getting into the debate about who gets more money, the authors or the publishers, books are a commodity that need to be paid for to support the authors who write them.
First, physical printed books are a commodity. Written works aren't, People who love books do write them no matter if they will be printed or not. Neither are ebooks. where duplication costs are virtually zero. Doing away with copyrights might actually improve the average reading quality by doing away with lots of mercenary writers, or even forcing them to do a better job.
Second, there is no need to bring back a library ebook.
The original texts, long lost. So we settle for confronting all the oldest manuscripts available, trusting God to have preserved the meaning, if not the exact tildes and commas, in the various translations and copies.
Not that there is much doubt about any text of consequence. All in all no originals for any ancient texts exist, but the Bible, by virtue of proximity to the originals and diversity of extant manuscripts is the best attested for ancient collection of texts.
Anyway, MS is in the proprietary customer lock-in, and MandrakeSoft is not. Better to compare to Red Hat, LibraNet and others. And do not guide yourself by the Linux name only: even SuSE is also in the proprietary lock-in game, even if a much milder version of it than MS.
>
Linux is about Free Software (or Open Source, depending on which idealogical leaning you have, pro-RMS or anti-RMS).
Cannot we decide on an issue without referring it to people who sport it or not? Specially as you refer to RMS, and he does make a point of talking about the issues, not about personal issues apart from the need for one to be principled.
That is, unless TCPA suceeds to the point of making all computers incapable of running anything but certified software, in this case a version of GNU/Linux carefully tailored to obey DRM.
Or perhaps free CD reader software will be banned as circumvention devices under DMCA.
Or they will shift the market towards DVD Audio and prosecute a Scandinavian teenager for breaking the encryption.
>
I should be able to do that some time around 2015?
The GNU Hurd is already running and available for developers. What is missing is some ease of use and scalability features necessary for achieving general availability status, also known as version 1.0.
So the missing piece is the groundwork to transform GNU SmallTalk from a C userland program into a GNU Hurd server.
>
I was thinking more along the lines of a true OO from the ground up OS
And that is what you would get, because the
SmallTalk server could be in equal footing with the C library server, which would provide POSIX compatibility. Once you had enough of an useable OS recoded in SmallTalk, you could even ditch POSIX compatibility from your environment.
The question: is SmallTalk adequate as a system programming language? C is, Lisp even more, but I think perhaps OO complexity and conceptual confusion would complicate things at the kernel level.
>
A single system unit might be of interest to a person who lives alone, but of what use is it for a normal family.
You are assuming a desktop PC. As I see it, it should be a single server with terminals all over the area -- I say area because I believe this should be done per building, block or quarter, not on each home.
Slashdot Mirror
Actually that would be either an insult, or an statement of fact, or both, but not an argument. To be an ad hominem argument you would have to say one is wrong because one is a jerk.
Now, you certainly did not insult me, but you in fact said I was incurring in the same error I identified in others, and that by virtue of my profession. That is what an ad hominem argument is.
And thus you avoided analysing the point I had made. That is what an ad hominem argument is for.
Incredible as it may seem, that is not true... there is lots of misguided talk about XML databases and DBMSs.
XML is text markup for human-machine interface, only that. Now the distinction you are making between sharing and storage is not clear enough.
There are actually three levels in data storage and representation: the physical, the logical and the user levels. The relational model is concerned with the logical and the user levels; the physical level is (should be) under the hood only, for DBAs, SysAdmins, system programmers and the like, not for application programmers and users.
Now, what is the difference between information sharing (communication) and the user level representation? None. What does XML adds to the relational model? Nothing, apart from overhead, restrictions & complexity. What does it substract? Simplicity, power, expressiveness, logical foundations & performance.
Well, it depends on your goals. If one wants to burn CPU cycles, waste storage, limit usage, employ armies of programmers, and generally deny access and power to the users, then one must not use relational systems indeed.
Ah, now I see where you are getting lost. You are identifying SQL with relational, and that is Simply Not True. SQL is indeed full of arbitrary restrictions, but that comes because it violates the relational model. If it had followed the relational model, it would be truly general.
In fact, there is no other data model that can provide general enough access to all kinds of data. All the other technologies are too low-level, and thus application-specific.
Could you make your case more objectively? I am sure I did not understood the idiom you used.
I am not a gamer by any means, but shareware Terminal Velocity was very good. It was not a MS-W32 game, but one of those that included its own operating system -- TVOS -- and drivers, to be loaded by (MS|DR|PC)-DOS.
It was so good that MS bought it, ported it to MS-W32, renamed it to Hellbender or something the like, retracted the DOS version and erased nearly all references to it from the Net.
Do we know indeed? I think the US is 70 years.
By the way, copy rights aren't permitted, they are granted. Copy rights are not a natural rights permission, but a state-enforced artificial monopoly grant.
That is an ad hominem argument. To have a valid point, you would point why one would prefer data in a hierarchical (XML) database to a relational one.
...everything looks like a nail. XML is text markup, it is not a generic data model. If one wants to make data available to computers, data must be in an accessible relational database system under an agreed-upon, domain-specific data model.
You can never scale, nor even be sure of your data integrity, without transaction. Fact. Period. If you do not understand that, you do not understand data. You might still manage to get some thing done, but with tremendous inefficiency, risk and limitations.
The question is not how well-written are the statements. But how well modelled is the database. A normalised database enables users to do much more intelligent queries. And most people code well in the sense that the statements are not ugly, but very bad indeed in failing to make use of the integrity constraints available in SQL, thus duplicating effort, wasting resources and risking data.
Pointers and NULLs, or GROUP BY sure enough should never had been included. But integrity constraint and transactions are hardly obscure, but truly essential. If you do not see that, you never understood SQL.
I agree they are a hack, and discount MySQL also on that basis. But all I heard of InnoDB is that it is an amazing piece of software, and that is is badly integrated but this impacts development (never forget specifying the table type), not operation. Why do you think it cannot be used in production?
First, let me admit that I just checked and MySQL does now have a decent basic SQL type system. But reading their documentation really drove me nuts: they still think of tables as the basic construct, and generally do not grok databases except as as programming utility. Treating transactions as optional... hah!
Not only that, but their comparision with PostgreSQL is really biased, more than is granted in vendor-written material. If they cannot be a little bit fairer, they should refrain from speech.
Now, I do not think PostgreSQL to be bloated. Evidence to the contrary welcome.
And if there is something that PostgreSQL does right, is in an extensible type system. MySQL does not plan to implement the single redeeming SQL feature!
Transactions are only supported in the optional table type InnoDB. Now, even the notion of an optional table type is unnecessary complexity: transactions must be the default behaviour. Not even PostgreSQL gets this as well as I would hope, but MySQL really is a mess. Now InnoDB is an amazing piece of software, but it needs to be the default, standard, do-not-even-think-about-it thing to do.
What about ISO SQL? Take anything from SQL 89 Entry Level, MySQL compliance is as bad as Oracle and even worse, without its robustness.
No, I mean that the language is not SQL, and there is not a clear direction about if and when it will reach compliance, and with which caveats.
One can argue that only a relational system can be a better DBMS, but sure there were and are non-relational DBMSs, for example SQL.
Yet nowadays data integrity is inherent part of a DBMS. Same as with OSs: initial ones would be little but loaders nowadays; today if someone launched a CP/M thingie it would never be accepted as a OS. The threshold shifts.
And? It does not make MySQL any better, same as the wider availability of MS-WXP does not make it any better.
Agreed, and I already told them so. I even tried to start a SourceForge project, but my time is not yet ripe. Anyway there is Alphora Dataphor already, which is not free in any meaning but has a free, feature-full demo available. And anyone can implement either Tutorial D, or D4, or any other valid D.
I would say fundamental, not slight
You have to do the integrity control, it doesn't yet. It is beginning to with InnoDB, but in a non-integrated, incomplete manner that needs an extra mile from you. So you can say it's not so good as it could be, but I would say it's not the real thing at all. Admittedly, no SQL flavour is or can be perfect, and no implementation of SQL is complete, but there are file access libraries, there are DBMSs, and things in between. MySQL is in between as yet.
Being scalable, generic, and declarative. MySQL may require less to start, but it sure requires more to develop and to scale.
If one starts with MySQL, eventually he will discover he needs something better. Then he will have to migrate, and in addition to the migration pain itself he will discover in horror that he could have done in a few declarative SQL integrity constraint lines what took lots of complex, error-prone procedural applicative code when using MySQL.
Now Oracle and PHP is not a good combination. PHP is not good with databases at all. And Oracle is know to be too complex and not conformant to anything but SQL Entry Level. But at least some of Oracle's complexity comes from it being scalable: you can connect to any account in any instance, but you never need more than a username/password@instance once your tnsnames.ora is set.
Because something else will require less coding and help you preserve your data integrity better, as well as scaling better.
See you still did not do your homework, Tablizer...
First, you have to decide what you are talking about, a database or a DBMS. Putting quotes around a database does not make it a DBMS, which is quite a different thing.
Second, a DBMS is a system to manage data. Keep its integrity, allow for perfoming backup, control and enable access and manipulation. So transactions are a part of what a DBMS is supposed to do. If one dillutes a concept to include X, X is happy, but the word becames useless.
Perhaps not, and actually InnoDB is quite good in itself. But yet it does not solve all MySQL problems, while simply using PostgreSQL does.
Then why use MySQL, which fails to implement it?
Freedom (source code openness somehow is not euphonic enough) is orthogonal to the relational model and to the SQL standard. If freedom is essential and SQL acceptable, PostgreSQL fits the bill much better. If not, then we do have Alphora Dataphor. It is a tough choice, but luckily we are not bound to suffer MySQL.
No, that means that a database is not a DBMS, and that a DBMS is not a database. See, a DBMS is a database management system, therefore it cannot be the thing it was created to manage. Similarly, data does not manage itself, but needs a DBMS (or a SysAdmin, operator or whatever else) to do that.
According to my definition it tries to be a DBMS, but fails for requiring too much of users and programmers. And it fails to be a SQL system too. But it sure can be used to suboptimally access a database.
Fuller answer at The Third Manifesto, Database Debunkings and elsewhere.
But to cut a long story short, SQL does not support relational prescriptions as data independence (SQL views are not consistently updateable), nor respect relational proscriptions (undifferentiated NULLs), nor abide by the fundamental relational principles (pointers violate the Information Principle, OO extensions mess the simple domain, attribute, tuple, relation that is central to the relational model).
Its language is not proper SQL at all: it does not support transactions properly, nor has the necessary data types, and has been adding features kinda haphazardly without neither admitting to past mistakes nor presenting a clear roadmap to either SQL or the relational model. It should be called PseudoSQL, or SubSQL, or SimplerThanSQL.
MySQL is not a database. A database is a collection of data.
MySQL is not a full DBMS either, because it leaves things like transaction control to the application unless you take some extra steps (InnoDB).
MySQL is not relational, SQL violating several relational prescriptions and proscriptions and MySQL not even raising to SQL's already faulty levels.
Not quite. TP monitors aren't message-oriented. But they are still a pretty fundamental piece of software for many applications that hasn't yet being implemented as free software.
First, physical printed books are a commodity. Written works aren't, People who love books do write them no matter if they will be printed or not. Neither are ebooks. where duplication costs are virtually zero. Doing away with copyrights might actually improve the average reading quality by doing away with lots of mercenary writers, or even forcing them to do a better job.
Second, there is no need to bring back a library ebook.
What is a PowerPoint display? Can something related to MS PowerPoint be high-tech?
The original texts, long lost. So we settle for confronting all the oldest manuscripts available, trusting God to have preserved the meaning, if not the exact tildes and commas, in the various translations and copies.
Not that there is much doubt about any text of consequence. All in all no originals for any ancient texts exist, but the Bible, by virtue of proximity to the originals and diversity of extant manuscripts is the best attested for ancient collection of texts.
It is not!.
Anyway, MS is in the proprietary customer lock-in, and MandrakeSoft is not. Better to compare to Red Hat, LibraNet and others. And do not guide yourself by the Linux name only: even SuSE is also in the proprietary lock-in game, even if a much milder version of it than MS.
Cannot we decide on an issue without referring it to people who sport it or not? Specially as you refer to RMS, and he does make a point of talking about the issues, not about personal issues apart from the need for one to be principled.
That is, unless TCPA suceeds to the point of making all computers incapable of running anything but certified software, in this case a version of GNU/Linux carefully tailored to obey DRM.
Or perhaps free CD reader software will be banned as circumvention devices under DMCA.
Or they will shift the market towards DVD Audio and prosecute a Scandinavian teenager for breaking the encryption.
Or all three alternatives are true.
The GNU Hurd is already running and available for developers. What is missing is some ease of use and scalability features necessary for achieving general availability status, also known as version 1.0.
So the missing piece is the groundwork to transform GNU SmallTalk from a C userland program into a GNU Hurd server.
And that is what you would get, because the SmallTalk server could be in equal footing with the C library server, which would provide POSIX compatibility. Once you had enough of an useable OS recoded in SmallTalk, you could even ditch POSIX compatibility from your environment.
The question: is SmallTalk adequate as a system programming language? C is, Lisp even more, but I think perhaps OO complexity and conceptual confusion would complicate things at the kernel level.
BTW, that is how MS-WNT was intended to be.
That should be possible by running GNU SmallTalk as a GNU Hurd server.
You are assuming a desktop PC. As I see it, it should be a single server with terminals all over the area -- I say area because I believe this should be done per building, block or quarter, not on each home.