As a long-time PHP developer, I have to agree with you somewhat. PHP5--Woohoo!! Ohh, wait... No namespace support? (Arggh... of all features to leave out...)
All the new features are sort of the stuff you would call a 'given' for object-oriented programming. Nice to have, but nothing to get really excited about.
Really the things that I found more interesting about PHP were all the system-oriented capabilities developed from version 4.3 onward, such as streams, sockets, direct I/O, etc... Of course, all these are givens in some languages too;), but at least PHP puts them all together easily at your fingertips.
The other cool things about PHP are the really dynamic things you can't do in Java, such as variable variables ($$varname), variable function calls ($function_name()), and the extended features for variable interpolation in strings. Also, features like array_map, create_function, and the overload extension are quite cool.
But yes, it looks like Perl 6 is going to up the ante big-time. Interesting to see where PHP goes in the interim, though.
Well, the point is not SQL, but the relational model. In fact, I think SQL itself often distracts from the relational model, because of it's complexity and inconsistency (See presentations by Hugh Darwen at www.thethirdmanifesto.com).
I'm not saying that "flat tables with keyed relationships" is wrong, but that it is only one part of the relational model (for example, my applications almost never talk to the base tables, but to views and set-returning functions). Really, there is no way to confer this 'Tao' on anyone with a quick sentence or two (there is no one 'aha' moment). It is all about set-oriented and predicate-oriented thinking, rather than object-oriented or procedural thinking. Used properly, this allows you to handle an incredible amount of business logic declaratively rather than procedurally. To grok it any further, I would heartily recommend you spend some time reading C.J. Date's book Foundation for Future Database Systems, as well as the material at www.thethirdmanifesto.com, and www.dbdebunk.com (yes, Fabian Pascal can be abrasive, but the discussions on the site are real eye-openers, especially some of the older material).
One thing that everyone should understand: even though Pascal, Date, etc... argue that SQL is a bad implementation of the relational model, they *still* agree that it provides value, and that it is miles better than its hierarchical database predecessors. Since it is their job(s) to provide a reasoned critique of the field, it is only natural for them to rigorously compare SQL to the goals of the relational model. Many of their complaints fall in these categories (although there is much more):
1. Does too much -- too many ways of doing the same thing, and too many unecessary operations that could be better done another way.
2. Overly complex -- the SQL 1999 standard was something like 1200 pages.
3. Allows programmer to circumvent relational integrity. Things like "hidden identifiers", pointers, etc...
4. Too wrapped up in implementation -- users must spend a lot of time understanding the physical storage, rather than focusing on queries in abstraction.
5. Many small inconsistencies in SQL itself
But the problems with SQL are impossible to judge if you only know SQL. It's like the people who used to ask what was wrong with a perfectly good typewriter that made people want to use a word processor. To any who are curious, I suggest you do some reading. The absolute best simple introductions for these problems are in a two online documents by Hugh Darwen at www.thethirdmanifesto.com. Look for "The Askew Wall", and "The Importance of Column Names".
>Types for instance - somewhat relevant when dealing with DB Servers and SQL - are a thing you don't want to touch with a ten-foot pole when designing a _model_.
In an ideal database language, types can be arbitrarily complex, or include user-defined constraints and operators, and can be created as domains over the base types. So in that case, indeed you would want types to be part of your data model. This sort of thing is exactly what Date, Darwen, and Pascal argue should be in a relational language.
In fact, some SQL systems have this capability, such as Oracle, PostgreSQL, and a few others.
And, in fact there is a modeling system that can take into account types, domains, and constraints. It is called Object Role Modeling (ORM). See www.orm.net.
One thing that everyone should understand: even though Pascal, Date, etc... argue that SQL is a bad implementation of the relational model, the *still* agree that it provides value, and that it is miles better than its hierarchical database predecessors. Since it is their job(s) to provide a reasoned critique of the field, it is only natural for them to rigorously compare SQL to the goals of the relational model. Many of their complaints fall in these categories:
1. Does too much -- too many ways of doing the same thing, and too many unecessary operations that could be better done another way.
2. Overly complex -- the SQL 1999 standard was something like 1200 pages.
3. Allows programmer to circumvent relational integrity. Things like "hidden identifiers", pointers, etc...
4. Too wrapped up in implementation -- users must spend a lot of time understanding the physical storage, rather than focusing on queries in abstraction.
5. Many small inconsistencies in SQL itself
But the problems with SQL are impossible to judge if you only know SQL. It's like the people who used to ask what was wrong with a perfectly good typewriter that made people want to use a wordprocessor. I suggest you do some reading. The absolute best simple explanations for these problems are in a couple online documents by Hugh Darwen at www.thethirdmanifesto.com. Look for "The Askew Wall", and "The Importance of Column Names".
Thank you... yes. While Fabian Pascal may be arrogant at times, that is just a personal thing. What he says should be evaluated for whether it is true, not whether it is arrogant.
And yes, the relational model is indeed *much* more than just flat tables with keyed relationships. I thought this upon my first encouters with the relational model, but after actually studying the concepts, I realized that there is in fact something much deeper going on, and that it has a conceptual integrity that I only wish could exist in the most of the rest of computing.
I don't know for sure, but I think this was a problem in FreeBSD 4.9, which was solved for 4.10 and for 5.2.x. Also, it might relate to which version of the Linux base you install. Stable FreeBSD tends to install version 6.x of linux-base, while I usually upgrade to 8.x, which is roughly compatible with RedHat 8.x.
Remember, though: you are not forced to use Linux emulation to run Java. You use linux emulation to install Java 1.4.2, but then you can compile a FreeBSD-native version (although I have never gone as far as that;)). You might want to spend some time on http://lists.freebsd.org/pipermail/freebsd-java/
Those are the current *binary packages*. In other words, this is what IS directly supported by Sun, allowing for an easy binary install. Whereas, if you want 1.4.2, you can get that, but you have to follow a few more steps, as mentioned by "APurplePolarBear" above. (and you have to wait through an interminable compile time -- fortunately, FreeBSD compiles like a champ, still handling its other processes, even for the most demanding portions of a compile)
>>...and if the price is right, poor design is largely unimportant, right?
I suppose that's something you'll enjoy saying to your clients when they realize their data is corrupted because an application bug circumvented your data model;-).
OK, sorry... that was a cheap shot.
But really, the question is largely one of awareness. Most developers are simply unaware of the logical capabilities of the relational model, so they assume that the things they would do with a "full" SQL system are almost the same as what they would do with MySQL. If that is the case, then of course there is less reason to use MySQL. (there are also those developers who ARE aware of those capabilities but are too much in love with writing extra code, so they prefer to dismiss them)
But, once you realize that with the proper SQL system...
1) You no longer need to worry about validating every little piece of data you insert. The design of the [table/view/procedure + constraints] IS the validation, if done properly.
2) When you need to change or add business logic, you can do it in just one place, and rest assured that no code elsewhere in the system, whether written by you or someone else, can circumvent this.
3) If for some reason another development team needs to access this data, you don't have to lose sleep wondering if they are screwing up your data or worse.
4) The *types* in your DBMS actually mean something. (MySQL is so bad at type enforcement that it is almost typeless)...and these are just a few of the things I am talking about. Yes, if you don't know about them, then of course they don't matter. I developed with MySQL for at least 2 years, blissfully unaware of these things. Then, I found out the capabilities of a real DBMS, and I was able in some cases to reduce my application code by 80-90%. That results in not only a better designed system, but in a *cheaper* system, since writing and debugging is much less trouble, and your liability for data corruption is far less.
Taking this in the larger context of your post, MySQL can be compared to fast food, such as McDonalds. It's cheap, it's everywhere, and sometimes it hits the spot, but a steady diet of it is... not recommended;-).
timothy got it exactly right. This is a very nice overview and collection of tutorials. It is definitely not designed as a reference, and that is the biggest thing missing for Mozilla/XUL right now. (For now, your best bet is a combination of the book + xulplanet.com, but XULPlanet's reference is just a little too terse to be useful on many things). IMHO to really document Mozilla in a useful way would take at least a couple 1000-page books.
Anyway, reading this book did provide me a great leap forward in my first large Mozilla app. For anyone who doubts whether serious work can be done in Mozilla, I will say... yes, but not with Mozilla alone. Obviously, Mozilla is intended as a GUI framework, so to accomplish serious work, you still need some system-level stuff to happen. My biggest quest in developing a kiosk-based app for Linux was how to integrate the two:
1. How to do this is not as readily apparent as I had thought. Of course, every web app developer's first thought would be to use Apache/PHP and basically treat the thing as a web app. But that ignores 90% of the true capability of Mozilla, so even though that was my home turf, I rejected that concept.
2. I thought maybe I would dig into that incredibly large pile of interfaces that makes up XPCOM, and see if I could play with the Python or Perl implementations, but my project was too much of a RAD situation to allow for that kind of time.
3. I thought maybe I could use MozPHP, which embeds a PHP intepreter in Mozilla. Turns out that it is near impossible to actually get it to work, and it really plunks you right back in the same old dynamic-document-building territory as the HTTP-based solution would. (In other words, you are using PHP to constantly re-write XUL content, which in the end can be very counter-productive and performance-intensive for the front end)
4. Finally, I realized that with JSlib (http://jslib.mozdev.org), I could use... sockets. In Javascript. Crazy... So, trying to keep in mind Eric Raymond's "Art of Unix Programming", I pulled together a few small daemons using PHP in CLI mode to handle back-end stuff, and used socket_select() to set up a message-dispatching system, keeping things nice and simple and "textual" (as ESR puts it) between PHP and Mozilla. Used the ":" as a delimiter, escaped text going in both directions using standard urlencoding (PHP and Javascript talk that language nicely). Asychronous notification... fun stuff. I can use PHP to call any Javascript method in Mozilla, and vice-versa with PHP, using variable function execution.
Performance? Performance is great. Remember, these are daemons, so I am not continually invoking the PHP interpeter to recompile and execute. And, since my front-end is a chrome:// app, it caches nicely after loading once.
It really was more fun than I thought it would be. All I can say is, give it a try.
Everyone screams about the speed of XUL apps, but they are missing quite a few details:
1. "A XUL app" != "the Mozilla browser". You can build a XUL app that runs only with the Gecko engine itself, which I believe is still less than 3 MB. The Mozilla Browser is quite a large app, when you consider all it's components. I have found smaller XUL apps to be quite snappy. For example, Firebird/Firefox is pretty darn fast, considering that it includes several megabytes of compressed XUL widgets.
2. Standard Mozilla uses GTK. I am willing to bet most of the people complaining about Mozilla are running KDE. Thus, half of the performance hit is due to loading a completely different GUI toolkit. I can't wait for the time when we will have a true Qt version of Mozilla.
3. Mozilla is not completely reliant on Javascript for programming. It is possible to use C, C++, Perl, Python, and I'm sure many more languages soon.
4. Mozilla apps that are run as "chrome" (as in chrome://appname/content) cache very nicely, so after loading once (which can be done in the background), they usually start up as fast as any other app.
5. ANYWAY... XUL itself is not tied to any particular intepreter or runtime. It is an XML spec for GUI definition that can be implemented in any way you want. Want compiled XUL apps... why not? The point of XUL is not the "scriptedness" of it, although that is nice for some types of projects, but the straightforward declarative nature of the syntax. There is no reason we can't use XUL as a base format for apps developed in many platforms. In fact, there is already an attempt at doing this for KDE, called Kaxul.
I guess I have to agree with one part of your post: the fact that America has a ridiculous double standard with respect to depicting violence.
But, every time I read one of these 'enlightened' diatribes about 'healthy sexuality' and porn, I am fairly certain of 4 things:
1. the writer is male 2. the writer is below the age of 30 3. the writer has no children (at least, no female children) 4. the writer probably has no idea what the word 'specious' means, in regards to his arguments (IE: picking a straw man argument like the Janet Jackson thing)
I'm not dismissing your post as a rant or flamebait. In fact, I really wish this sort of talk were that easily dismissable.
It's not these edge cases, the "where do you draw the line?" situations that worry me. It's the hard-core stuff that manages to make its way all over the internet, by disguising itself. Everyone knows that there are things you can receive in your email or stumble across that will sicken you, unless your mind is already numbed to them: almost all of these involve some sort of debasement of women. I mean, EXTREME debasement of women. I can't imagine how I would explain this stuff to my 4-year old daughter if she stumbled across anything like that (don't worry, she only uses the web when we are present, and I have Mozilla installed with pop-up blocking, etc...).
To me, the real question to me about porn and about its increasing ubiquity is not whether we are violating some prudish old spinster's view of morality, but about what the large majority of it teaches children of their own worth as human beings. Oh, I suppose it's possible for there to be some sort of porn out there that encourages mutual respect between men and women, but has anyone here ever seen anything it?
Anyone who has looked at any porn at all realizes that 99% of it teaches men one thing and women another:
Men: I am nothing if I don't have oversized genitals and a brutally indifferent personality.
Women: I am nothing. Use me for whatever you want.
And in fact it is a _lot_ more than just transactions and foreign keys. SQL92 and SQL99 specify much of the abstract capability that forms the core of the relational model, such as views, declarative constraints, domains, user-defined functions (procedures) and more.
No simple abstraction layer, or even a complex one, will bridge the gap between a DBMS that has these features and one that doesn't, unless you "dumb down" the more capable DBMS.
In a serious application, the only way to achieve a cross-db implementation to this dumbed-down level is to implement many of these relational features in the application code, in which case you have just tripled the amount of code you need to write.
Exactly... Why do these companies like RedHat think that somehow it will be better for them if they pretend there is no comflict between them and Microsoft?
That strategy doesn't work. Every company that has tried it has failed. It's time one of these guys squared his shoulders and just says it: we think we've got something better than Microsoft. I guarantee, if they actually do this in the public eye, people will pay attention. Merely raising the question will show enough chutzpah to get some attention. They should be taking out ads saying this stuff, instead of tiptoeing around the giant.
When are we going to see TV ads showing how cool KDE or Gnome can be in comparison to boring old Windows? Start doing feature comparisons, etc...
Although I have my doubts about the technical quality of Lindows, Michael Robertson is one of the few Linux businesspeople that actually has the guts to come out and say this sort of stuff, and he is probably the most likely person to bring Linux to the average user's desktop.
I wasn't talking about any type of integrity constraint, but specifically the type of "integrity constraints one can apply in a relational system", as I said in my original post. Specifically, I mean that in a relational system one can apply integrity constraints in a declarative, relational manner. Ergo, if any other database system became able to apply such integrity constraints, it would become relational. And: 1) true integrity constraints are not the same as modeling objects consistently. 2) SQL itself is only a halfway solution to declarative integrity constraints. 3) "Business rules" systems might be considered an example of the application of declarative integrity.
1) MySQL does have referential integrity, since version 4.0, if you use innoDB tables. Not that I really care, since I use much more capable DBMSs.
2) Foreign key (referential) integrity is only one small aspect of integrity constraint capability. Of course constraints can be implemented in any application, but they usually most be done in a messy, implementation-centric manner. In general, the idea behind any sort of object store looks very similar to the "network" database model used in the 70s, (which itself was an enhancement of the hierarchical systems that came before that). Essentially, you still have to be concerned about such things as the path from one class to another, and "object IDs", etc...
Let's forget about SQL for a moment: look at at the relational model itself as a method to allow one to express constraints and data manipulation in a purely logical manner without worrying about how the system actually implements the storage or constraints in the back end. Given that, there is absolutely nothing preventing some clever developer from implementing a relational language interface to Prevayler, which would then make it... an RDBMS. (In fact, that would be quite cool;-). If that developer were to do it without SQL, but with a truly relational language, such as C.J. Date's "D", that would be even cooler)
> I don't really know what you mean when you say Prevayler can't ensure that your data is safe and correct.
I think Matt is not talking about robustness of memory storage but the integrity constraints one can apply in a relational system, which have never really been possible with any other approach.
...and by this, I mean that any system which truly and logically allows one to apply integrity constraints will in the end become a relational DBMS of its own. It's not about SQL per se, but about the application of logic to data management.
My non-OO solution to "large applications" is to divide them into many smaller applications which feed on a big-ass Oracle database center. This works (if done well). That way you mostly only have to grok the schemas instead of piles and piles of code...
While I am still deliberating on the place OOP has, I am in definite agreement on the usefulness of the database as a way to handle application structure. This seems to be the direction certain branches of enterprise development are taking with the "business rules" approach, which builds an application on the database schema, and allows the developer/maintainer to write declarative statements that control all aspects of the application, in the attempt to separate application-level logic from implementation-level logic. (IMHO a much more impressive goal than the old "separating content from logic" approach)
And I agree with Tablizer's first sentiment. I think often terms like "object-oriented" and "procedural" become almost meaningless. Almost like throwing around words like "left wing" and "conservative". What's more important is *how* your application is built, and what type of application it is. There are some excellent applications written in plain C, such as Apache, PostgreSQL, most of FreeBSD, etc... and there are some perfectly horrible messes written in C++, such as Windows ME.
So really I am convinced the real difference is in application architecture, planning, and plain old clear thinking. These can be done in OOP, procedural, fuctional approaches, or in some of the newer experiments such as "aspect-oriented" programming, or the business rules approach.
I haven't seen any recent comparisons between MySQL and PostgreSQL. AFAIR, The last comparison done by MySQL compared the MySQL4 beta with an older version of PostgreSQL, hardly apples-to-apples.
Without knowing more about your application it's hard to say "yes" to your question, but I will give a qualified yes, if your system will involve any complex queries. In my experience, MySQL only beats PostgreSQL for speed when the queries are simple. Also, remember that with views, stored procedures, prepared queries, cursors, etc... there are many ways to tweak your system for performance that are not available in MySQL. So again the comparison is not really apples-to-apples, because PostgreSQL happens to have a lot more apples;-).
Also, there have been some really interesting benchmarks for the upcoming verion 7.4 of PostgreSQL (I have been testing the beta version for months without a single problem).
The other thing to consider is that PostgreSQL's greater ANSI-SQL compliance means that it is *much* easier to migrate to other enterprise DBMSs if you eventually have the need. Developing with MySQL involves many workarounds, special cases, and non-standard syntax. (hmm... come to think of it, that might actually be a strategy for lock-in... sound familiar?)
PostgreSQL handles auto-incrementing in the style of Oracle, using sequences. It's a different concept, but much more powerful. Performance is just fine for this.
I'm not sure what you mean by "convenience variables", but really once you delve into the land of stored procedures, you can turn anything, even rowsets, into variables.
Yes, PostgreSQL takes more time to learn, but take it from a former MySQL user: it is well worth the trouble.
Well, since I already handle updating on multi-table queries with views anyway, I don't think there will be any problem automating that. Really, the great thing is that you have complete freedom anyway. Creating a rule in PostgreSQL to handle multi-table views is as straightforward as:
CREATE RULE my_rule AS ON INSERT TO my_view DO INSTEAD(
-- insert to first table
INSERT INTO table1 (col1, col2, col3)
VALUES (NEW.val1, NEW.val2, NEW.val3)
WHERE [condition];
-- insert to 2nd table
INSERT INTO table2 (col1, col2)
VALUES (NEW.val4, NEW.val5)
WHERE [condition]; );
You do have to create a separate rule for each of INSERT, DELETE, and UPDATE though, but it is quite simple. Also, view definitions themselves are really just rules in PostgreSQL, so you can also write a SELECT rule that defines any kind of complex behavior you want, such as inserting a timestamp into a log table whenever there is a SELECT. Fun stuff...;-)
Apparently coming soon, these rules will be created automatically for non-ambiguous views. The great thing is that you will still be able to modify these rules, to make any logic happen as the result of a view update.
1. If you install PHP as an Apache module, you don't have to recompile Apache. And, there are two other very easy ways of loading extension modules without even recompiling PHP: a) call the extension inside the php.ini script (so all you have to do is restart Apache), or b) use the dl(extension) function to dynamically load the module inside your scrip, in which case you don't even need to restart Apache.
2. true, but probably not a major deal to fix, if enough people cared. Unfortunately, the average ISP is stunningly clueless about security anyway.
3. Socket/streams are a moving target because they are *still in development*, hello... (Not for production use). Otherwise, yes there were some unfortunate changes in certain functions, but hardly on a massive scale. 99.9% of the problems with ISPs upgrading to find "all scripts broken" had to do with the simple, stupid question of register_globals, and those ISPs could have fixed that by changing exactly three bytes worth of data in php.ini (setting "off" to "on").
Have I mentioned how clueless I consider most ISPs? Never mind...
Not that I think PHP is perfect. My gripes with it have been in the area of inconsistent OO support, and lack of namespaces, as well as somewhat ugly scoping rules (I wish it had the "my" keyword, like Perl). I hope that PHP 5 will fix most of these, although apparently namespaces will not be included in the first release:-(.
Slashdot Mirror
As a long-time PHP developer, I have to agree with you somewhat. PHP5--Woohoo!! Ohh, wait... No namespace support? (Arggh... of all features to leave out...)
;), but at least PHP puts them all together easily at your fingertips.
All the new features are sort of the stuff you would call a 'given' for object-oriented programming. Nice to have, but nothing to get really excited about.
Really the things that I found more interesting about PHP were all the system-oriented capabilities developed from version 4.3 onward, such as streams, sockets, direct I/O, etc... Of course, all these are givens in some languages too
The other cool things about PHP are the really dynamic things you can't do in Java, such as variable variables ($$varname), variable function calls ($function_name()), and the extended features for variable interpolation in strings. Also, features like array_map, create_function, and the overload extension are quite cool.
But yes, it looks like Perl 6 is going to up the ante big-time. Interesting to see where PHP goes in the interim, though.
Well, the point is not SQL, but the relational model. In fact, I think SQL itself often distracts from the relational model, because of it's complexity and inconsistency (See presentations by Hugh Darwen at www.thethirdmanifesto.com).
I'm not saying that "flat tables with keyed relationships" is wrong, but that it is only one part of the relational model (for example, my applications almost never talk to the base tables, but to views and set-returning functions). Really, there is no way to confer this 'Tao' on anyone with a quick sentence or two (there is no one 'aha' moment). It is all about set-oriented and predicate-oriented thinking, rather than object-oriented or procedural thinking. Used properly, this allows you to handle an incredible amount of business logic declaratively rather than procedurally. To grok it any further, I would heartily recommend you spend some time reading C.J. Date's book Foundation for Future Database Systems, as well as the material at www.thethirdmanifesto.com, and www.dbdebunk.com (yes, Fabian Pascal can be abrasive, but the discussions on the site are real eye-openers, especially some of the older material).
One thing that everyone should understand: even though Pascal, Date, etc... argue that SQL is a bad implementation of the relational model, they *still* agree that it provides value, and that it is miles better than its hierarchical database predecessors. Since it is their job(s) to provide a reasoned critique of the field, it is only natural for them to rigorously compare SQL to the goals of the relational model. Many of their complaints fall in these categories (although there is much more):
1. Does too much -- too many ways of doing the same thing, and too many unecessary operations that could be better done another way.
2. Overly complex -- the SQL 1999 standard was something like 1200 pages.
3. Allows programmer to circumvent relational integrity. Things like "hidden identifiers", pointers, etc...
4. Too wrapped up in implementation -- users must spend a lot of time understanding the physical storage, rather than focusing on queries in abstraction.
5. Many small inconsistencies in SQL itself
But the problems with SQL are impossible to judge if you only know SQL. It's like the people who used to ask what was wrong with a perfectly good typewriter that made people want to use a word processor. To any who are curious, I suggest you do some reading. The absolute best simple introductions for these problems are in a two online documents by Hugh Darwen at www.thethirdmanifesto.com. Look for "The Askew Wall", and "The Importance of Column Names".
>Types for instance - somewhat relevant when dealing with DB Servers and SQL - are a thing you don't want to touch with a ten-foot pole when designing a _model_.
In an ideal database language, types can be arbitrarily complex, or include user-defined constraints and operators, and can be created as domains over the base types. So in that case, indeed you would want types to be part of your data model. This sort of thing is exactly what Date, Darwen, and Pascal argue should be in a relational language.
In fact, some SQL systems have this capability, such as Oracle, PostgreSQL, and a few others.
And, in fact there is a modeling system that can take into account types, domains, and constraints. It is called Object Role Modeling (ORM). See www.orm.net.
One thing that everyone should understand: even though Pascal, Date, etc... argue that SQL is a bad implementation of the relational model, the *still* agree that it provides value, and that it is miles better than its hierarchical database predecessors. Since it is their job(s) to provide a reasoned critique of the field, it is only natural for them to rigorously compare SQL to the goals of the relational model. Many of their complaints fall in these categories:
1. Does too much -- too many ways of doing the same thing, and too many unecessary operations that could be better done another way.
2. Overly complex -- the SQL 1999 standard was something like 1200 pages.
3. Allows programmer to circumvent relational integrity. Things like "hidden identifiers", pointers, etc...
4. Too wrapped up in implementation -- users must spend a lot of time understanding the physical storage, rather than focusing on queries in abstraction.
5. Many small inconsistencies in SQL itself
But the problems with SQL are impossible to judge if you only know SQL. It's like the people who used to ask what was wrong with a perfectly good typewriter that made people want to use a wordprocessor. I suggest you do some reading. The absolute best simple explanations for these problems are in a couple online documents by Hugh Darwen at www.thethirdmanifesto.com. Look for "The Askew Wall", and "The Importance of Column Names".
Thank you... yes. While Fabian Pascal may be arrogant at times, that is just a personal thing. What he says should be evaluated for whether it is true, not whether it is arrogant.
And yes, the relational model is indeed *much* more than just flat tables with keyed relationships. I thought this upon my first encouters with the relational model, but after actually studying the concepts, I realized that there is in fact something much deeper going on, and that it has a conceptual integrity that I only wish could exist in the most of the rest of computing.
I don't know for sure, but I think this was a problem in FreeBSD 4.9, which was solved for 4.10 and for 5.2.x. Also, it might relate to which version of the Linux base you install. Stable FreeBSD tends to install version 6.x of linux-base, while I usually upgrade to 8.x, which is roughly compatible with RedHat 8.x.
;)). You might want to spend some time on http://lists.freebsd.org/pipermail/freebsd-java/
Remember, though: you are not forced to use Linux emulation to run Java. You use linux emulation to install Java 1.4.2, but then you can compile a FreeBSD-native version (although I have never gone as far as that
Those are the current *binary packages*. In other words, this is what IS directly supported by Sun, allowing for an easy binary install. Whereas, if you want 1.4.2, you can get that, but you have to follow a few more steps, as mentioned by "APurplePolarBear" above. (and you have to wait through an interminable compile time -- fortunately, FreeBSD compiles like a champ, still handling its other processes, even for the most demanding portions of a compile)
XUL apps can be loaded from the server (as long as the server has the right mime-type), but there are various security restrictions.
See the Mozilla Amazon browser (http://www.infodraft.com/~faser/mab/) as an example of a XUL app that can be launched remotely.
>> ...and if the price is right, poor design is largely unimportant, right?
;-).
...and these are just a few of the things I am talking about. Yes, if you don't know about them, then of course they don't matter. I developed with MySQL for at least 2 years, blissfully unaware of these things. Then, I found out the capabilities of a real DBMS, and I was able in some cases to reduce my application code by 80-90%. That results in not only a better designed system, but in a *cheaper* system, since writing and debugging is much less trouble, and your liability for data corruption is far less.
... not recommended ;-).
I suppose that's something you'll enjoy saying to your clients when they realize their data is corrupted because an application bug circumvented your data model
OK, sorry... that was a cheap shot.
But really, the question is largely one of awareness. Most developers are simply unaware of the logical capabilities of the relational model, so they assume that the things they would do with a "full" SQL system are almost the same as what they would do with MySQL. If that is the case, then of course there is less reason to use MySQL. (there are also those developers who ARE aware of those capabilities but are too much in love with writing extra code, so they prefer to dismiss them)
But, once you realize that with the proper SQL system...
1) You no longer need to worry about validating every little piece of data you insert. The design of the [table/view/procedure + constraints] IS the validation, if done properly.
2) When you need to change or add business logic, you can do it in just one place, and rest assured that no code elsewhere in the system, whether written by you or someone else, can circumvent this.
3) If for some reason another development team needs to access this data, you don't have to lose sleep wondering if they are screwing up your data or worse.
4) The *types* in your DBMS actually mean something. (MySQL is so bad at type enforcement that it is almost typeless)
Taking this in the larger context of your post, MySQL can be compared to fast food, such as McDonalds. It's cheap, it's everywhere, and sometimes it hits the spot, but a steady diet of it is
timothy got it exactly right. This is a very nice overview and collection of tutorials. It is definitely not designed as a reference, and that is the biggest thing missing for Mozilla/XUL right now. (For now, your best bet is a combination of the book + xulplanet.com, but XULPlanet's reference is just a little too terse to be useful on many things). IMHO to really document Mozilla in a useful way would take at least a couple 1000-page books.
... sockets. In Javascript. Crazy... So, trying to keep in mind Eric Raymond's "Art of Unix Programming", I pulled together a few small daemons using PHP in CLI mode to handle back-end stuff, and used socket_select() to set up a message-dispatching system, keeping things nice and simple and "textual" (as ESR puts it) between PHP and Mozilla. Used the ":" as a delimiter, escaped text going in both directions using standard urlencoding (PHP and Javascript talk that language nicely). Asychronous notification... fun stuff. I can use PHP to call any Javascript method in Mozilla, and vice-versa with PHP, using variable function execution.
Anyway, reading this book did provide me a great leap forward in my first large Mozilla app. For anyone who doubts whether serious work can be done in Mozilla, I will say... yes, but not with Mozilla alone. Obviously, Mozilla is intended as a GUI framework, so to accomplish serious work, you still need some system-level stuff to happen. My biggest quest in developing a kiosk-based app for Linux was how to integrate the two:
1. How to do this is not as readily apparent as I had thought. Of course, every web app developer's first thought would be to use Apache/PHP and basically treat the thing as a web app. But that ignores 90% of the true capability of Mozilla, so even though that was my home turf, I rejected that concept.
2. I thought maybe I would dig into that incredibly large pile of interfaces that makes up XPCOM, and see if I could play with the Python or Perl implementations, but my project was too much of a RAD situation to allow for that kind of time.
3. I thought maybe I could use MozPHP, which embeds a PHP intepreter in Mozilla. Turns out that it is near impossible to actually get it to work, and it really plunks you right back in the same old dynamic-document-building territory as the HTTP-based solution would. (In other words, you are using PHP to constantly re-write XUL content, which in the end can be very counter-productive and performance-intensive for the front end)
4. Finally, I realized that with JSlib (http://jslib.mozdev.org), I could use
Performance? Performance is great. Remember, these are daemons, so I am not continually invoking the PHP interpeter to recompile and execute. And, since my front-end is a chrome:// app, it caches nicely after loading once.
It really was more fun than I thought it would be. All I can say is, give it a try.
Everyone screams about the speed of XUL apps, but they are missing quite a few details:
1. "A XUL app" != "the Mozilla browser". You can build a XUL app that runs only with the Gecko engine itself, which I believe is still less than 3 MB. The Mozilla Browser is quite a large app, when you consider all it's components. I have found smaller XUL apps to be quite snappy. For example, Firebird/Firefox is pretty darn fast, considering that it includes several megabytes of compressed XUL widgets.
2. Standard Mozilla uses GTK. I am willing to bet most of the people complaining about Mozilla are running KDE. Thus, half of the performance hit is due to loading a completely different GUI toolkit. I can't wait for the time when we will have a true Qt version of Mozilla.
3. Mozilla is not completely reliant on Javascript for programming. It is possible to use C, C++, Perl, Python, and I'm sure many more languages soon.
4. Mozilla apps that are run as "chrome" (as in chrome://appname/content) cache very nicely, so after loading once (which can be done in the background), they usually start up as fast as any other app.
5. ANYWAY... XUL itself is not tied to any particular intepreter or runtime. It is an XML spec for GUI definition that can be implemented in any way you want. Want compiled XUL apps... why not? The point of XUL is not the "scriptedness" of it, although that is nice for some types of projects, but the straightforward declarative nature of the syntax. There is no reason we can't use XUL as a base format for apps developed in many platforms. In fact, there is already an attempt at doing this for KDE, called Kaxul.
I guess I have to agree with one part of your post: the fact that America has a ridiculous double standard with respect to depicting violence.
But, every time I read one of these 'enlightened' diatribes about 'healthy sexuality' and porn, I am fairly certain of 4 things:
1. the writer is male
2. the writer is below the age of 30
3. the writer has no children (at least, no female children)
4. the writer probably has no idea what the word 'specious' means, in regards to his arguments (IE: picking a straw man argument like the Janet Jackson thing)
I'm not dismissing your post as a rant or flamebait. In fact, I really wish this sort of talk were that easily dismissable.
It's not these edge cases, the "where do you draw the line?" situations that worry me. It's the hard-core stuff that manages to make its way all over the internet, by disguising itself. Everyone knows that there are things you can receive in your email or stumble across that will sicken you, unless your mind is already numbed to them: almost all of these involve some sort of debasement of women. I mean, EXTREME debasement of women. I can't imagine how I would explain this stuff to my 4-year old daughter if she stumbled across anything like that (don't worry, she only uses the web when we are present, and I have Mozilla installed with pop-up blocking, etc...).
To me, the real question to me about porn and about its increasing ubiquity is not whether we are violating some prudish old spinster's view of morality, but about what the large majority of it teaches children of their own worth as human beings. Oh, I suppose it's possible for there to be some sort of porn out there that encourages mutual respect between men and women, but has anyone here ever seen anything it?
Anyone who has looked at any porn at all realizes that 99% of it teaches men one thing and women another:
Men: I am nothing if I don't have oversized genitals and a brutally indifferent personality.
Women: I am nothing. Use me for whatever you want.
And in fact it is a _lot_ more than just transactions and foreign keys. SQL92 and SQL99 specify much of the abstract capability that forms the core of the relational model, such as views, declarative constraints, domains, user-defined functions (procedures) and more.
No simple abstraction layer, or even a complex one, will bridge the gap between a DBMS that has these features and one that doesn't, unless you "dumb down" the more capable DBMS.
In a serious application, the only way to achieve a cross-db implementation to this dumbed-down level is to implement many of these relational features in the application code, in which case you have just tripled the amount of code you need to write.
> It claims to be more liberal, yet encourages theft by others.
Once more...
IT'S NOT THEFT IF IT HAS BEEN GIVEN AWAY.
(...tired of political word-mangling...)
Exactly... Why do these companies like RedHat think that somehow it will be better for them if they pretend there is no comflict between them and Microsoft?
That strategy doesn't work. Every company that has tried it has failed. It's time one of these guys squared his shoulders and just says it: we think we've got something better than Microsoft. I guarantee, if they actually do this in the public eye, people will pay attention. Merely raising the question will show enough chutzpah to get some attention. They should be taking out ads saying this stuff, instead of tiptoeing around the giant.
When are we going to see TV ads showing how cool KDE or Gnome can be in comparison to boring old Windows? Start doing feature comparisons, etc...
Although I have my doubts about the technical quality of Lindows, Michael Robertson is one of the few Linux businesspeople that actually has the guts to come out and say this sort of stuff, and he is probably the most likely person to bring Linux to the average user's desktop.
Se my other comment in response to Elwood P Dowd.
I wasn't talking about any type of integrity constraint, but specifically the type of "integrity constraints one can apply in a relational system", as I said in my original post. Specifically, I mean that in a relational system one can apply integrity constraints in a declarative, relational manner. Ergo, if any other database system became able to apply such integrity constraints, it would become relational. And: 1) true integrity constraints are not the same as modeling objects consistently. 2) SQL itself is only a halfway solution to declarative integrity constraints. 3) "Business rules" systems might be considered an example of the application of declarative integrity.
Well...
;-). If that developer were to do it without SQL, but with a truly relational language, such as C.J. Date's "D", that would be even cooler)
1) MySQL does have referential integrity, since version 4.0, if you use innoDB tables. Not that I really care, since I use much more capable DBMSs.
2) Foreign key (referential) integrity is only one small aspect of integrity constraint capability. Of course constraints can be implemented in any application, but they usually most be done in a messy, implementation-centric manner. In general, the idea behind any sort of object store looks very similar to the "network" database model used in the 70s, (which itself was an enhancement of the hierarchical systems that came before that). Essentially, you still have to be concerned about such things as the path from one class to another, and "object IDs", etc...
Let's forget about SQL for a moment: look at at the relational model itself as a method to allow one to express constraints and data manipulation in a purely logical manner without worrying about how the system actually implements the storage or constraints in the back end. Given that, there is absolutely nothing preventing some clever developer from implementing a relational language interface to Prevayler, which would then make it... an RDBMS. (In fact, that would be quite cool
> I don't really know what you mean when you say Prevayler can't ensure that your data is safe and correct.
...and by this, I mean that any system which truly and logically allows one to apply integrity constraints will in the end become a relational DBMS of its own. It's not about SQL per se, but about the application of logic to data management.
I think Matt is not talking about robustness of memory storage but the integrity constraints one can apply in a relational system, which have never really been possible with any other approach.
While I am still deliberating on the place OOP has, I am in definite agreement on the usefulness of the database as a way to handle application structure. This seems to be the direction certain branches of enterprise development are taking with the "business rules" approach, which builds an application on the database schema, and allows the developer/maintainer to write declarative statements that control all aspects of the application, in the attempt to separate application-level logic from implementation-level logic. (IMHO a much more impressive goal than the old "separating content from logic" approach)
And I agree with Tablizer's first sentiment. I think often terms like "object-oriented" and "procedural" become almost meaningless. Almost like throwing around words like "left wing" and "conservative". What's more important is *how* your application is built, and what type of application it is. There are some excellent applications written in plain C, such as Apache, PostgreSQL, most of FreeBSD, etc... and there are some perfectly horrible messes written in C++, such as Windows ME.
So really I am convinced the real difference is in application architecture, planning, and plain old clear thinking. These can be done in OOP, procedural, fuctional approaches, or in some of the newer experiments such as "aspect-oriented" programming, or the business rules approach.
I haven't seen any recent comparisons between MySQL and PostgreSQL. AFAIR, The last comparison done by MySQL compared the MySQL4 beta with an older version of PostgreSQL, hardly apples-to-apples.
;-).
Without knowing more about your application it's hard to say "yes" to your question, but I will give a qualified yes, if your system will involve any complex queries. In my experience, MySQL only beats PostgreSQL for speed when the queries are simple. Also, remember that with views, stored procedures, prepared queries, cursors, etc... there are many ways to tweak your system for performance that are not available in MySQL. So again the comparison is not really apples-to-apples, because PostgreSQL happens to have a lot more apples
Also, there have been some really interesting benchmarks for the upcoming verion 7.4 of PostgreSQL (I have been testing the beta version for months without a single problem).
The other thing to consider is that PostgreSQL's greater ANSI-SQL compliance means that it is *much* easier to migrate to other enterprise DBMSs if you eventually have the need. Developing with MySQL involves many workarounds, special cases, and non-standard syntax. (hmm... come to think of it, that might actually be a strategy for lock-in... sound familiar?)
PostgreSQL handles auto-incrementing in the style of Oracle, using sequences. It's a different concept, but much more powerful. Performance is just fine for this.
I'm not sure what you mean by "convenience variables", but really once you delve into the land of stored procedures, you can turn anything, even rowsets, into variables.
Yes, PostgreSQL takes more time to learn, but take it from a former MySQL user: it is well worth the trouble.
Well, since I already handle updating on multi-table queries with views anyway, I don't think there will be any problem automating that. Really, the great thing is that you have complete freedom anyway. Creating a rule in PostgreSQL to handle multi-table views is as straightforward as:
;-)
CREATE RULE my_rule AS
ON INSERT TO my_view DO INSTEAD(
-- insert to first table
INSERT INTO table1 (col1, col2, col3)
VALUES (NEW.val1, NEW.val2, NEW.val3)
WHERE [condition];
-- insert to 2nd table
INSERT INTO table2 (col1, col2)
VALUES (NEW.val4, NEW.val5)
WHERE [condition];
);
You do have to create a separate rule for each of INSERT, DELETE, and UPDATE though, but it is quite simple. Also, view definitions themselves are really just rules in PostgreSQL, so you can also write a SELECT rule that defines any kind of complex behavior you want, such as inserting a timestamp into a log table whenever there is a SELECT. Fun stuff...
Apparently coming soon, these rules will be created automatically for non-ambiguous views. The great thing is that you will still be able to modify these rules, to make any logic happen as the result of a view update.
In that case, one could just as easily argue that true capitalism and true democracy have never been tried.
1. If you install PHP as an Apache module, you don't have to recompile Apache. And, there are two other very easy ways of loading extension modules without even recompiling PHP: a) call the extension inside the php.ini script (so all you have to do is restart Apache), or b) use the dl(extension) function to dynamically load the module inside your scrip, in which case you don't even need to restart Apache.
:-(.
2. true, but probably not a major deal to fix, if enough people cared. Unfortunately, the average ISP is stunningly clueless about security anyway.
3. Socket/streams are a moving target because they are *still in development*, hello... (Not for production use). Otherwise, yes there were some unfortunate changes in certain functions, but hardly on a massive scale. 99.9% of the problems with ISPs upgrading to find "all scripts broken" had to do with the simple, stupid question of register_globals, and those ISPs could have fixed that by changing exactly three bytes worth of data in php.ini (setting "off" to "on").
Have I mentioned how clueless I consider most ISPs? Never mind...
Not that I think PHP is perfect. My gripes with it have been in the area of inconsistent OO support, and lack of namespaces, as well as somewhat ugly scoping rules (I wish it had the "my" keyword, like Perl). I hope that PHP 5 will fix most of these, although apparently namespaces will not be included in the first release