Yes, version 4 will be an improvement, BUT it is still missing many key features like views, triggers, full outer joins, update with subselect, that are already present in Postgres, and the fact is I've been using the features that MySQL is promising for the future for a year and a half now.
Not to mention column and table constraints, stored procedures, extensible datatypes, user-defined operators, query rewrite rules, and schema and domain support.
Oh no. I mean, yes, you could just store XML as a string in a BLOB column, but that's no better than just storing as a file.
A custom XML datatype would not treat the XML as a blob, but actually parse the XML upon input into the table, storing an internal representation (probably as an associative array) which would allow custom operators to traverse the tree, visit nodes, etc...
But, it would also allow you to perform relational queries and place integrity constraints on your XML documents.
To explain further, I will use a specific example: PostgreSQL allows you to create custom datatypes, even importing C functions to handle the input and output of these types. Thus, theoretically, you should be able to create a custom datatype called "xmldoc", and use code from a standard C library which handles XML, such as libxml, or expat, which will parse the XML string into an internal data structure, and vice-versa upon output.
(I must stress, this is theoretical. I haven't had the time or need for such a thing, but according to the documentation, it should be possible)
Dude, You're still missing the point! I never said that object systems can't maintain this or that constraint (although they don't have as rigorous a logical foundation under them). What I am saying is that IF you maintain that constraint ONLY in your application layer, then the constraint can easily be circumvented by anything or anyone who is connecting to the database by any other means (or different versions of the same application). In other words, this is a recipe for data corruption, in large heterogenous-client systems. Besides the heterogenous aspect, if the constraints are preserved in the database, then bugs in the application are far less disastrous.
My examples are not "bad" or "good", they are simply true examples of constraints that most serious DB admins keep in the database layer, regardless of how well the application layer also models the same constraints. It's not rocket science.
Also, I seem to recall another Asimov story in the same vein, where education has been replaced by some sort of brain upload from a computer, except for the few abnormal people whose minds are somehow not "capable", so they must do remedial education the old-fashioned way, with books.
Most people think of the incapables as the losers of society ("Learning without the machine? That sounds like the poor fellow who tried to fly without a hovercar."), but they don't realize that all technological advances are actually done by these deviants. They are the only ones with real creativity.
Actually, this is frighteningly like much of modern education, anyway... How many college graduates do you know whose education essentially consists of rote training in a specific career, with no attention paid to critical thinking, experimentation, well-rounded knowledge, etc...?
How can data constraints be outside of the application if the application's responsible for the data?
Here, I think you are definitely missing a piece of the puzzle about relational databases. Try reading C.J. Date's Introduction to Database Systems. It's a classic of C.S.
But let's get really basic here: enforcement of foreign key relationships is an example of a constraint that lives outside of the application. With a REFERENCES constraint on a column, for example, then no client application can add a value in that column unless it exists in the related column of another table. The application must apply this constraint, but the database enforces it. Most high-end SQL systems allow for many more types of constraints, such as CHECK constraints (don't allow a value in this column unless it meets certain parameters), DOMAIN constraints (these are really cool, essentially letting you have the equivalent of named subtypes, and much more), and of course, the infamous TRIGGER, which makes up for SQL's weakness in declarative logic.
Well, not to carry this on infinitely, but this is a good discussion;-). I agree that all in all there are benefits and drawbacks to every application design method.
And, I agree that databases are not necessary for ALL information involved in any application. Often times a system like Prevayler might be a perfect intermediate complement to a back-end database where permanent data is archived, for example.
Point is, where mission-critical or enterprise-critical data is centralized as an organization's primary record of all business doings, I am convinced that the data constraints and integrity should live outside the application.
Of course SQL is not a perfect solution. I said that somewhat tongue-in-cheek, in my last post, meaning a common data storage and retrieval language is a perfect solution to multiple application front-ends. The top minds in Relational theory complain that SQL is too implementation-dependent, and still misses the boat on certain areas of predicate logic, etc... While this may seem like academic trivia, it is absolutely central to most of the problems we currently have with SQL systems.
However, with a well-designed database, there is no need to sprinkle SQL ad-hoc throughout your application. You can even have ALL interaction with the database occur through stored procedures. Thus, whenever changing structure in the database, you can simply change the stored procedure without changing your C code at all (Or, only changing the necessary arguments). And some procedural languages, such as PostgreSQL's Pl/PgSQL even allow for function overloading, which can even further preserve your application code from changes.
Also, with a well-designed application, I would think the data access methods would be abstracted, rather than just hard-coded everywhere in the system. But, maybe that's just my dream world view...
My good friend the anti-oop guy makes a good point. Yes, and OODBMS can also be network-oriented. But the network database was just an attempt to work around the logical limitations of hierarchical storage. The main advantage was that a child node is not limited to one parent. But once again, a relational approach can do that and much more.
Like I said in another reply, NDB's and HDB's are too different in base philosophy from RDB's, and they will never fully get along (barring some big theorical breakthrough).
We don't need a theoretical breakthrough. The relational data model is just straightforward logic, as applied to data storage. What we need is an implementation breakthrough. Even the best SQL systems only implement about 70% of the advantages of the relational model, and suffer from needless performance problems, due to being too tied to physical mapping of tables and views.
This isn't a relational database. Those techs you mention are used to make a denormalised SQL database act like a normalised SQL database; they aren't needed if your relational database is normalised or you're not using a relational database at all.
I don't believe I have missed the point at all. I am painfully aware that the technology in question is not a relational DBMS. But, normalization (with foreign key constraints) is only the beginning of the constraints needed to create a real database. There are constraints that can be placed on columns, on tables, even on specific types with some systems, and there are *database* constraints (when the system is in condition X, don't allow Y, etc...). Triggers are not the optimal solution for database-level constraints, but that is how most SQL systems are limited.
Yes, I agree that SQL systems are limited, by design. The world has not seen a truly relational DBMS, with the possible exception of Dataphor (which I dislike for other reasons). The relational model is a logical model. It doesn't "care" which implementation you use. DBMS's are just applications. There is no reason you can't do one in Java. It's not about the language, but about the concept. The relational model offers logical advantages that cannot be found in ANY other system. If any other system achieved those advantages, it would become de facto relational. End of story.
No, the point is being missed by a great many people. This whole thread here really is about physical storage optimization, and running in memory. There is no reason a relational DBMS can't run in memory. That is simply an implementation detail. If the Prevayler application framework achieved the level of logical relational operators and constraints of an RDBMS, then it would become an RDBMS. But it seems pretty obvious that this is not its purpose.
I'm glad you like DBDebunk.com. It helped me, see these concepts in much more clarity. Go back and read the site more carefully, and you will see every argument in this Slashdot thread examined and reexamined. Look for the whole logical-physical confusion thing;-).
This is language-specific, or application-specific.
Oh? Which one, then? Language, or application? Have you read the page?
Yes, it has many languages, but if you try to access your Java Prevayler application data from PHP or Perl, you are going to have to re-implement all your integrity constraints in those languages. That's my point. No longer will you have a single point of control for your business rules, or the logical model of your data.
It's NOT intrinsically language specific, although if the languages you're wanting to use together don't have any way of talking to each other you're out of luck (although I don't see how SQL could help you there).
Huh? This is the most obvious one of all. With SQL, my VB, Java and Perl application could all interact with the same DBMS without needing to talk to each other. Thats a perfect solution in the real world.
Your other problems are real, of course; but they're also very real for any real database, relational or otherwise.
I understand that complex database design is always a difficult thing. And I recognize that there is nothing a relational DBMS can do that can't be re-implemented in application code. But that's my whole point. Separation of operations. Your data should have a single point of control for the logical constraints in the data, and that point of control should be a logical firewall between the data, and everything else that happens in the application.
Also, in the end there is also nothing that an OO DBMS can do that a truly relational DBMS can't. This is what many people don't understand about the true relational model. With the right kind of RDBMS (not the typical SQL ones), there are many more things that are possible than just messing around with base types and simple 3NF normalization. And with updateable views, functions, and logical RULEs (check out PostgreSQL), you can tailor the external access to the application in any way you want, without changing your base table design. This is power.
Yes, data integrity is one of the major considerations here. I'm willing to bet that by the time you implemented the equivalent of constraints, triggers, etc... in a system like this, you would be running no faster than a typical SQL DBMS, and you would have thousands of bugs as you reinvent the wheel. But there are even more considerations than integrity. This is language-specific, or application-specific. What do you do when you need to access your data from another application? Even if it is possible, that means you have to implement all your integrity checks again in that application.
Essentially, what this looks like is just another OO method of heirarchical (or perhaps "multi-valued") data storage. This is nothing new. It will suffer all of the historical problems the industry has had with hierarchical storage (there is a reason the relational data model was invented: the problems IBM had with hierarchical data). For example, what happens to existing data when you need to change your logical schema or business rules? The cost of re-ordering or reformatting _every_ single stored object since the beginning of your application would be ridiculous, and in some cases even impossible. How do you track dependencies? In theory, these kinds of systems will work fine, if your application stays exactly as created, and if the nature of the data doesn't change, and if no other applications are involved. In other words, NOT in the real world.
I have a nick-name for hierarchical data storaqe: "headache-ical".
As a fellow guitarist, I have to ask what is your favorite guitar, and what is the worst thing you have done to it?
Also, would you please critique The Hamster Song by my friend David Goodman. (Would the fact that he also lives in South Florida, and his name is Dave, unduly influence your opinion?)
In 1995, the first website I ever did (www.worldford.com, for a Ford dealership in Fort Lauderdale, FL) used frames for a consistent left-hand navigation system. Of course, the website no longer exists in that form, but I have plenty of witnesses, as well as my backup files, the original contract for the job, etc...
I thought it was pretty cool, too. We used 3D buttons to look like a car stereo, with a green LED-style readout at the top telling you which section you were in. Anyone remember this one?
(No, it doesn't show up in the Wayback Machine, which only goes to 1996 anyway)
AFAIK, QUEL was originally developed specifically for Ingres, and was considered a better implementation of a relational query language than SQL, by such people as Codd, Date, et al.
(Short discussion on the history of Ingres here, here, and here)
If so, that's interesting, when you realize that Ingres is the predecessor to Postgres, which later became the PostgreSQL project. Postgres originally used the (theoretically more relational) QUEL language of Ingres, but with SQL being the de facto standard, they decided to change to PostgreSQL.
Go to pgsql.com. They have commercial support, just like any regular company. In fact, at the higher levels of support, they even throw in a commercial replication/distributed-querying system. This is really the best of both worlds. You get the full source of the application for your own review, and you get to call an expert anytime you like.
>>Actually, no, breaking up documents into many discrete units is a requirement of the normalization required by relational theory.
Actually, as Date himself would say, that all just depends on what the logical requirements are. Breaking up data is for logical reasons, to remove redundancy. But, if your database design is to handle documents as discrete entities, then why not?
Date himself argues for the existence of a native XML datatype. This would mean you could have an XML document stored in a single column. The big difference is that this datatype would not be just a blob. It would require a valid XML document, and it would have operators that allow you to interact with the DOM. it would also mean you can change your schema, using a combination of view, for example, to present your data any other way desired.
The whole point that the (serious) relational guys keep saying is that there's no need to throw away the relational model in order to get certain additional advantages. Literally any sort of logical operation on data should be able to exist inside the relational model. And, even more importantly, physical storage can be implemented any way desired for performance. The only difference is that the relational model requires complete logical control over data, which no other model truly handles.
You don't have to throw away one to get the other.
>But how is it difficult to do xhtml in templates?
That wasn't me saying that. I was responding to the original poster. You are correct; XHTML is completely a client-side thing, so it has nothing to do with PHP support.
By the way, there is a cool PHP class that dynamically generates well-formed, indented XHTML: phpHTMLlib.
>>Oh and something I'm curious about (too lazy to look it up, I guess) what sort of exception handling does PHP have (ie it's equivalent of 'try {} catch {} finally {}')? What sort of logging modules are available?
>Well it has that. It doesn't have/manual/en/ref.errorfunc.php [php.net] (in summary, it blows)
PHP5 will have try/catch/finally. Yes, these days it still blows.
>>I'd also be curious to know about how PHP's templating systems measure up, from someone who's had experience with this sort of thing...
>Well templating is quite well done. There's FastTemplate and Pear's one. It's difficult to do XHTML templates without XML support. I guess it's not easy.
There are quite a few good templating engines with PHP, including two which are PHP modules (compiled C code), providing good performance.
>>OO in PHP isn't great, and that's what most people have been waiting on PHP 4.3 to fix
No, that's what people have been waiting on PHP 5 with Zend 2.0 to fix. Big difference.
However, your comments about XML and string handling have nothing to do with PHP's OO capabilities. I would argue that PHP's string handling and regex are better than the standard ones you find in Java or.NET.
XML support? Well, yes PHP isn't a native XML-handling language, nor is Java (.NET might be another story).
With any standard programming language, though, XML support is not "native". You have to include the appropriate modules or classes. Ditto with Java.
Even more fun; you can use the Perl 'heredoc' format, in which you don't need to escape either set of quotes:
echo <<<END_OF_STRING
anything you 'want' here, except the "token" above, including $variable interpolation, even with some nice ${embed}ding methods, even with some more {$complex->expressions()}.
Good old Lester Thurow. (Or, as others came to call him "Less-than Thorough").
The zero-sum economy is one of those wonderful humanist myths. It comes from the same scientific fatalism that attempts to make every person just a cog in a machine, without any independent choice. (Ergo, the wise, all-knowing leaders who somehow are above this limitation can make the decisions we can't make for ourselves)
Think about it: an economy depends on a collection of individual choices. If enough people refuse to work, or refuse to work as hard as another group, then of course the economy will have trouble. If the government siphons personal effort into non-productive areas, then of course that economony will be strained a little more. But, if everyone works hard, even though they might be "stealing" jobs from one another, the end result is a much more healthy economy than if everyone is carefully protected in whatever mediocre position. It's not rocket science.
In fact, it seems history has proven that the more you limit individual choice, the more you limit your economy. Interestingly, this seems to compare well with work in distributed "swarming" algorithms, etc... in the computer world: you can't absolutely predict the outcome, but it is possible for a swarm of automonous units to do things that could not be accomplished with the old-fashioned 'top-down' approach. (Read Michael Crichton's "Prey", for a good intro to these concepts.).
Thurow isn't the first economist to be a negative boo-hooer. There have always been experts crying that the end is near. Thomas Malthus, back in the 18th century, predicted that within a few decades the world would no longer be able to sustain economic growth, and massive starvation/anarchy/whatever would occur.
These people have all failed to see that through hard work and ingenuity, human beings have consistently managed to do more with less. And, willingness of individuals to work hard, while sometimes affecting others in negative ways, temporarily, has an overall effect of lifting the total economy. Take three people living on an acre of land. If all three till the ground and grow vegetables, they will be much better off than if only one does. If you force the most successful vegetable grower to stop until the others catch up, then the net result is...less vegetables. It's not rocket science.
Anyway, for more than 200 years, Americans have experienced an economic freedom that was unheard of anywhere in the world. For this reason, of course, tough-minded individuals who didn't mind taking their chances emigrated from all over the world to the U.S. I'm not trying to paint a completely rosy picture. Of course there was repression, but that always involved *restricting* personal choice. If we had not repressed women or certain ethnic groups, I am convinced America would be even richer now. But I believe the end result was undeniable: freedom produces more wealth than restriction.
Slashdot Mirror
It's going to take more than a wrapper to get stored procedures into MySQL (lol).
But that is an excellent idea for PostgreSQL.
Not to mention column and table constraints, stored procedures, extensible datatypes, user-defined operators, query rewrite rules, and schema and domain support.
>wouldn't that just be storing a string?
Oh no. I mean, yes, you could just store XML as a string in a BLOB column, but that's no better than just storing as a file.
A custom XML datatype would not treat the XML as a blob, but actually parse the XML upon input into the table, storing an internal representation (probably as an associative array) which would allow custom operators to traverse the tree, visit nodes, etc...
But, it would also allow you to perform relational queries and place integrity constraints on your XML documents.
To explain further, I will use a specific example: PostgreSQL allows you to create custom datatypes, even importing C functions to handle the input and output of these types. Thus, theoretically, you should be able to create a custom datatype called "xmldoc", and use code from a standard C library which handles XML, such as libxml, or expat, which will parse the XML string into an internal data structure, and vice-versa upon output.
(I must stress, this is theoretical. I haven't had the time or need for such a thing, but according to the documentation, it should be possible)
For more opinions to make you think:
http://www.dbazine.com/pascal9.html
http://www.dbazine.com/pascal8.html
And here, C.J. Date argues that a truly relational DBMS should be able to support an XML data type:
http://www.dbdebunk.com/lauri1.htm
(PostgreSQL is an example of a DBMS with extensible types)
Dude, You're still missing the point! I never said that object systems can't maintain this or that constraint (although they don't have as rigorous a logical foundation under them). What I am saying is that IF you maintain that constraint ONLY in your application layer, then the constraint can easily be circumvented by anything or anyone who is connecting to the database by any other means (or different versions of the same application). In other words, this is a recipe for data corruption, in large heterogenous-client systems. Besides the heterogenous aspect, if the constraints are preserved in the database, then bugs in the application are far less disastrous.
My examples are not "bad" or "good", they are simply true examples of constraints that most serious DB admins keep in the database layer, regardless of how well the application layer also models the same constraints. It's not rocket science.
Yes, I remember this one too. Quite a hoot.
Also, I seem to recall another Asimov story in the same vein, where education has been replaced by some sort of brain upload from a computer, except for the few abnormal people whose minds are somehow not "capable", so they must do remedial education the old-fashioned way, with books.
Most people think of the incapables as the losers of society ("Learning without the machine? That sounds like the poor fellow who tried to fly without a hovercar."), but they don't realize that all technological advances are actually done by these deviants. They are the only ones with real creativity.
Actually, this is frighteningly like much of modern education, anyway... How many college graduates do you know whose education essentially consists of rote training in a specific career, with no attention paid to critical thinking, experimentation, well-rounded knowledge, etc...?
Anyone remember that story? What was the title?
Here, I think you are definitely missing a piece of the puzzle about relational databases. Try reading C.J. Date's Introduction to Database Systems. It's a classic of C.S.
But let's get really basic here: enforcement of foreign key relationships is an example of a constraint that lives outside of the application. With a REFERENCES constraint on a column, for example, then no client application can add a value in that column unless it exists in the related column of another table. The application must apply this constraint, but the database enforces it. Most high-end SQL systems allow for many more types of constraints, such as CHECK constraints (don't allow a value in this column unless it meets certain parameters), DOMAIN constraints (these are really cool, essentially letting you have the equivalent of named subtypes, and much more), and of course, the infamous TRIGGER, which makes up for SQL's weakness in declarative logic.
Well, not to carry this on infinitely, but this is a good discussion ;-). I agree that all in all there are benefits and drawbacks to every application design method.
And, I agree that databases are not necessary for ALL information involved in any application. Often times a system like Prevayler might be a perfect intermediate complement to a back-end database where permanent data is archived, for example.
Point is, where mission-critical or enterprise-critical data is centralized as an organization's primary record of all business doings, I am convinced that the data constraints and integrity should live outside the application.
Of course SQL is not a perfect solution. I said that somewhat tongue-in-cheek, in my last post, meaning a common data storage and retrieval language is a perfect solution to multiple application front-ends. The top minds in Relational theory complain that SQL is too implementation-dependent, and still misses the boat on certain areas of predicate logic, etc... While this may seem like academic trivia, it is absolutely central to most of the problems we currently have with SQL systems.
However, with a well-designed database, there is no need to sprinkle SQL ad-hoc throughout your application. You can even have ALL interaction with the database occur through stored procedures. Thus, whenever changing structure in the database, you can simply change the stored procedure without changing your C code at all (Or, only changing the necessary arguments). And some procedural languages, such as PostgreSQL's Pl/PgSQL even allow for function overloading, which can even further preserve your application code from changes.
Also, with a well-designed application, I would think the data access methods would be abstracted, rather than just hard-coded everywhere in the system. But, maybe that's just my dream world view...
We don't need a theoretical breakthrough. The relational data model is just straightforward logic, as applied to data storage. What we need is an implementation breakthrough. Even the best SQL systems only implement about 70% of the advantages of the relational model, and suffer from needless performance problems, due to being too tied to physical mapping of tables and views.
I don't believe I have missed the point at all. I am painfully aware that the technology in question is not a relational DBMS. But, normalization (with foreign key constraints) is only the beginning of the constraints needed to create a real database. There are constraints that can be placed on columns, on tables, even on specific types with some systems, and there are *database* constraints (when the system is in condition X, don't allow Y, etc...). Triggers are not the optimal solution for database-level constraints, but that is how most SQL systems are limited.
Yes, I agree that SQL systems are limited, by design. The world has not seen a truly relational DBMS, with the possible exception of Dataphor (which I dislike for other reasons). The relational model is a logical model. It doesn't "care" which implementation you use. DBMS's are just applications. There is no reason you can't do one in Java. It's not about the language, but about the concept. The relational model offers logical advantages that cannot be found in ANY other system. If any other system achieved those advantages, it would become de facto relational. End of story.
No, the point is being missed by a great many people. This whole thread here really is about physical storage optimization, and running in memory. There is no reason a relational DBMS can't run in memory. That is simply an implementation detail. If the Prevayler application framework achieved the level of logical relational operators and constraints of an RDBMS, then it would become an RDBMS. But it seems pretty obvious that this is not its purpose.
I'm glad you like DBDebunk.com. It helped me, see these concepts in much more clarity. Go back and read the site more carefully, and you will see every argument in this Slashdot thread examined and reexamined. Look for the whole logical-physical confusion thing
Yes, it has many languages, but if you try to access your Java Prevayler application data from PHP or Perl, you are going to have to re-implement all your integrity constraints in those languages. That's my point. No longer will you have a single point of control for your business rules, or the logical model of your data.
Huh? This is the most obvious one of all. With SQL, my VB, Java and Perl application could all interact with the same DBMS without needing to talk to each other. Thats a perfect solution in the real world.
I understand that complex database design is always a difficult thing. And I recognize that there is nothing a relational DBMS can do that can't be re-implemented in application code. But that's my whole point. Separation of operations. Your data should have a single point of control for the logical constraints in the data, and that point of control should be a logical firewall between the data, and everything else that happens in the application.
Also, in the end there is also nothing that an OO DBMS can do that a truly relational DBMS can't. This is what many people don't understand about the true relational model. With the right kind of RDBMS (not the typical SQL ones), there are many more things that are possible than just messing around with base types and simple 3NF normalization. And with updateable views, functions, and logical RULEs (check out PostgreSQL), you can tailor the external access to the application in any way you want, without changing your base table design. This is power.
Aha.
Someone's been reading DBDebunk.com again.
Yes, data integrity is one of the major considerations here. I'm willing to bet that by the time you implemented the equivalent of constraints, triggers, etc... in a system like this, you would be running no faster than a typical SQL DBMS, and you would have thousands of bugs as you reinvent the wheel. But there are even more considerations than integrity. This is language-specific, or application-specific. What do you do when you need to access your data from another application? Even if it is possible, that means you have to implement all your integrity checks again in that application.
Essentially, what this looks like is just another OO method of heirarchical (or perhaps "multi-valued") data storage. This is nothing new. It will suffer all of the historical problems the industry has had with hierarchical storage (there is a reason the relational data model was invented: the problems IBM had with hierarchical data). For example, what happens to existing data when you need to change your logical schema or business rules? The cost of re-ordering or reformatting _every_ single stored object since the beginning of your application would be ridiculous, and in some cases even impossible. How do you track dependencies? In theory, these kinds of systems will work fine, if your application stays exactly as created, and if the nature of the data doesn't change, and if no other applications are involved. In other words, NOT in the real world.
I have a nick-name for hierarchical data storaqe: "headache-ical".
Hi Dave,
As a fellow guitarist, I have to ask what is your favorite guitar, and what is the worst thing you have done to it?
Also, would you please critique The Hamster Song by my friend David Goodman. (Would the fact that he also lives in South Florida, and his name is Dave, unduly influence your opinion?)
In 1995, the first website I ever did (www.worldford.com, for a Ford dealership in Fort Lauderdale, FL) used frames for a consistent left-hand navigation system. Of course, the website no longer exists in that form, but I have plenty of witnesses, as well as my backup files, the original contract for the job, etc...
I thought it was pretty cool, too. We used 3D buttons to look like a car stereo, with a green LED-style readout at the top telling you which section you were in. Anyone remember this one?
(No, it doesn't show up in the Wayback Machine, which only goes to 1996 anyway)
Why on earth was this modded "funny"? It's actually true.
AFAIK, QUEL was originally developed specifically for Ingres, and was considered a better implementation of a relational query language than SQL, by such people as Codd, Date, et al.
(Short discussion on the history of Ingres here, here, and here)
If so, that's interesting, when you realize that Ingres is the predecessor to Postgres, which later became the PostgreSQL project. Postgres originally used the (theoretically more relational) QUEL language of Ingres, but with SQL being the de facto standard, they decided to change to PostgreSQL.
Go to pgsql.com. They have commercial support, just like any regular company. In fact, at the higher levels of support, they even throw in a commercial replication/distributed-querying system. This is really the best of both worlds. You get the full source of the application for your own review, and you get to call an expert anytime you like.
OK, ya got me... First time I've fallen for one of these (lol). It's been a long week.
...and all the bank needs to manage your account is a paper ledger with holes punched for a nice ring-binder.
Data *management* is every bit as important as data storage and retrieval. And don't even get me started on statistics and reporting.
/leandro dives into the RDBMS fray again ;-)
>>Actually, no, breaking up documents into many discrete units is a requirement of the normalization required by relational theory.
Actually, as Date himself would say, that all just depends on what the logical requirements are. Breaking up data is for logical reasons, to remove redundancy. But, if your database design is to handle documents as discrete entities, then why not?
Date himself argues for the existence of a native XML datatype. This would mean you could have an XML document stored in a single column. The big difference is that this datatype would not be just a blob. It would require a valid XML document, and it would have operators that allow you to interact with the DOM. it would also mean you can change your schema, using a combination of view, for example, to present your data any other way desired.
The whole point that the (serious) relational guys keep saying is that there's no need to throw away the relational model in order to get certain additional advantages. Literally any sort of logical operation on data should be able to exist inside the relational model. And, even more importantly, physical storage can be implemented any way desired for performance. The only difference is that the relational model requires complete logical control over data, which no other model truly handles.
You don't have to throw away one to get the other.
>But how is it difficult to do xhtml in templates?
That wasn't me saying that. I was responding to the original poster. You are correct; XHTML is completely a client-side thing, so it has nothing to do with PHP support.
By the way, there is a cool PHP class that dynamically generates well-formed, indented XHTML: phpHTMLlib.
>> What does PHP use in terms of a browser agent (a la LWP)?
:-) (http://www.php.net/manual/en/ref.dba.php)
/manual/en/ref.errorfunc.php [php.net] (in summary, it blows)
>None. They've had a long time to do something.
Umm... http://php.net/curl (this is only one of several methods you can use)
>There's no treebuilder or concept of nodes or anything like that in PHP. They're still thinking in flat structures.
http://php.net/dom-xml (admittedly experimental, but it's been around for almost 3 years)
>> Is there really no support simple filebased db persistence? (by which I mean something along the lines of tieing a hash to BerkleyDB)
>It doesn't.
BerkelyDB? Who uses that thing anymore?
>>Oh and something I'm curious about (too lazy to look it up, I guess) what sort of exception handling does PHP have (ie it's equivalent of 'try {} catch {} finally {}')? What sort of logging modules are available?
>Well it has that. It doesn't have
PHP5 will have try/catch/finally. Yes, these days it still blows.
>>I'd also be curious to know about how PHP's templating systems measure up, from someone who's had experience with this sort of thing...
>Well templating is quite well done. There's FastTemplate and Pear's one. It's difficult to do XHTML templates without XML support. I guess it's not easy.
There are quite a few good templating engines with PHP, including two which are PHP modules (compiled C code), providing good performance.
>>OO in PHP isn't great, and that's what most people have been waiting on PHP 4.3 to fix
.NET.
No, that's what people have been waiting on PHP 5 with Zend 2.0 to fix. Big difference.
However, your comments about XML and string handling have nothing to do with PHP's OO capabilities. I would argue that PHP's string handling and regex are better than the standard ones you find in Java or
XML support? Well, yes PHP isn't a native XML-handling language, nor is Java (.NET might be another story).
With any standard programming language, though, XML support is not "native". You have to include the appropriate modules or classes. Ditto with Java.
Even more fun; you can use the Perl 'heredoc' format, in which you don't need to escape either set of quotes:
echo <<<END_OF_STRING
anything you 'want' here, except the "token" above,
including $variable interpolation, even with some
nice ${embed}ding methods, even with some more
{$complex->expressions()}.
END_OF_STRING;
(http://www.php.net/manual/en/language.types.s tring.php#language.types.string.syntax.heredoc)
Good old Lester Thurow. (Or, as others came to call him "Less-than Thorough").
The zero-sum economy is one of those wonderful humanist myths. It comes from the same scientific fatalism that attempts to make every person just a cog in a machine, without any independent choice. (Ergo, the wise, all-knowing leaders who somehow are above this limitation can make the decisions we can't make for ourselves)
Think about it: an economy depends on a collection of individual choices. If enough people refuse to work, or refuse to work as hard as another group, then of course the economy will have trouble. If the government siphons personal effort into non-productive areas, then of course that economony will be strained a little more. But, if everyone works hard, even though they might be "stealing" jobs from one another, the end result is a much more healthy economy than if everyone is carefully protected in whatever mediocre position. It's not rocket science.
In fact, it seems history has proven that the more you limit individual choice, the more you limit your economy. Interestingly, this seems to compare well with work in distributed "swarming" algorithms, etc... in the computer world: you can't absolutely predict the outcome, but it is possible for a swarm of automonous units to do things that could not be accomplished with the old-fashioned 'top-down' approach. (Read Michael Crichton's "Prey", for a good intro to these concepts.).
Thurow isn't the first economist to be a negative boo-hooer. There have always been experts crying that the end is near. Thomas Malthus, back in the 18th century, predicted that within a few decades the world would no longer be able to sustain economic growth, and massive starvation/anarchy/whatever would occur.
These people have all failed to see that through hard work and ingenuity, human beings have consistently managed to do more with less. And, willingness of individuals to work hard, while sometimes affecting others in negative ways, temporarily, has an overall effect of lifting the total economy. Take three people living on an acre of land. If all three till the ground and grow vegetables, they will be much better off than if only one does. If you force the most successful vegetable grower to stop until the others catch up, then the net result is...less vegetables. It's not rocket science.
Anyway, for more than 200 years, Americans have experienced an economic freedom that was unheard of anywhere in the world. For this reason, of course, tough-minded individuals who didn't mind taking their chances emigrated from all over the world to the U.S. I'm not trying to paint a completely rosy picture. Of course there was repression, but that always involved *restricting* personal choice. If we had not repressed women or certain ethnic groups, I am convinced America would be even richer now. But I believe the end result was undeniable: freedom produces more wealth than restriction.