I may have misunderstood your point, but it seems you are looking at an RDBMS as merely a storage layer.
I look at an RDBMS as a system that is an integral part of the development process. Errors, constraints, warnings, user-defined types, procedures, and sometimes triggers are all there to aid in the development process. An RDBMS can abstract the data access by using views to separate logical representation and physical storage.
All the applications that access the same data set are able to use these facilities to develop rapidly without interfering with the other applications. The other applications may even be older versions of the same application.
The fact that a constraint isn't used after the application is "complete" is irrelevent if the application is never "complete".
If the entire system is perfectly specified from the beginning, and the code is well planned out, then you can engineer the storage layer as you describe. An RDBMS is for the people whose requirements are constantly evolving, and who make use of the development aid that an RDBMS provides.
If you're testing a new version of an application, and you get a constraint violation, or a type input error, or an RI violation, that is a godsend for debugging. You're happy it didn't corrupt the main data set, and you know exactly which application is causing the error, and when.
PostgreSQL is great, and I encourage you to at least give it a try. Certainly write to the mailing lists with your experiences, particularly if you are having difficulty with something (see the pgsql-general list).
VACUUM is nothing to be scared of. In the upcoming 8.1 (currently in beta) you don't even need to think about it. It's basically just a command that tells PostgreSQL "Now's a good time to do some cleanup and maintenance work". Now, in 8.1, it automatically uses statistics to determine the best time to do that work, and how often.
Also, for the past few years, VACUUM is non-locking. That means that if PostgreSQL chooses to VACUUM just before a lot of activity starts, the VACUUM won't interfere with that activity.
In practice, VACUUM usually only causes a problem if you go a long time without VACUUMing. After a while, the planner can start to make bad choices, and the tables can get cluttered with dead tuples.
But, like I said, you don't need to know about this stuff because it's all automatic in 8.1.
The server does not care about "\q" at all. The server only accepts SQL queries.
"\q" is a command for the "psql" program (which is the command-line client that postgres admins usually use). When psql sees "\q" it terminates itself, which is just the client software. The server of course keeps running.
I haven't found MySQL to be too sensitive to crashes -- except once, in the case of a table with c.28M records and indices on several fields. This is used in a read-only application, being rebuilt from sources every quarter.
I think once counts as "too many" when talking about database crashes. I have never had an issue with PostgreSQL's reliability (however, Linux of course has issues, so sometimes the database server might have a problem with that).
I also wonder how MySQL would manage to corrupt itself when it's a read-only database.
Why on earth would you want your RDBMS vendor cramming their lousy procedural programming language down your throat?
If you have 10 applications accessing the same set of data, you may want the database to enforce constraints using procedural code.
If you try to do it client-side, than a bug in one application can cause failures in other applications. Unless, of course, you try to do huge amounts of data validation each and every time before you retrieve data.
If you do it client-side, it will most likely put more load on the database server, since a few stored procedures might be negligible compared with the application pulling in more data for processing, and possibly performaing extra joins. And the difference in the size of the client code will be huge.
Also, it's great to be able to separate physical layout from the view the applications have. Procedures are an important part of building the views, &c., that make that happen.
I agree in the sense that you don't want the database server running the application logic. But when it's closely tied to the data model, a few lines of well-placed code can make a huge difference.
If you give up stored procedures/functions, you ALSO give up: - user-defined types (isn't this important?) - triggers - functional indexes (how can you do without?!) - functions that return a relation - user-defined aggregates - many types of data constraints
The native procedural language that comes with PostgreSQL is called PL/pgSQL.
Also, PostgreSQL comes with several other server-side languages, and the mechanism is extensible (so anyone can add additional procedural languages at run time). Popular procedural languages include PL/perl, PL/java, and C.
but ALL dbms's are slightly different from eachother
MySQL is far away and completely alone in it's flavor of SQL and behavior. There are all kinds of strange things it does, like use the "`" to quote identifiers. Oracle, PostgreSQL, SQL Server, &c. all have their differences. But they all look a lot more like eachother than any of them look like MySQL.
The biggest and most 'incompatible' difference between postgres and mysql is the autoincrement field really, the rest is just small fish to fix.
Actually, the biggest differences are regarding types and constraints, in my opinion. For instance, MySQL thinks February 31st is a date, PostgreSQL does not. PostgreSQL enforces constraints, MySQL does not. MySQL NULL handling is non-standard.
How many times does the media report that the Global demand for grain has outstripped supply five years running
That sentence makes little or no sense. Unless of course governments are artificially reducing the price, in which case of course that will happen. The good news is that it's easily fixed: the governments involved just need to stop using price controls.
It seems kind of strange to me because the US artificially increases the price of grain.
A rational point, but I think you miss the point of a RDBMS. The point is that it's an extra abstraction layer above the filesystem, not that it provides more features.
The abstraction seperates physical data layout from the access layer. You can change the physical layout of the data for a second version of an application, and still let the first version see the data the way it always did. Two applications can see the same data in different ways. And you can prevent a buggy application from causing problems in other applications that access the same data by using constraints.
It's about making willing transactions with willing peers. And those transactions only take place when they benefit both parties. So, it's about making zillions of mutually-beneficial transactions.
What do you think the term "convicted monopolist" means?
It means that we are no longer ruled by law, we are ruled by men. Anti-monopolist laws are subjective and unpredictible. The judge and the DOJ have all the power. It's not at all clear the point when someone transitions from a law-abiding citizen to a monopolist.
The rule of law is more important than whatever dumb reason they are attacking MS. It's not like they accomplished anything anyway, it's the "now what?" sydrome. They convicted MS, but they have no idea what to do about it.
So, what is the legal status of such projects ? Can Sun shut them down ? I'm not asking if it is profitable for Sun to do this, I'm asking if it is possible for them to do this ?
It's legal. It's just that Sun has made a sophisticated product very carefully with very high quality standards, and it is difficult for open source developers to match that in a fully-compatible way.
In short, is it safe to begin new projects in Java, or should I look into Ruby or something ? Or should I just stick to C and forget all about this current fad of object-orientation ?-)
Sun will be there, and Java will be there. And if not, some open product will likely suit your needs (GIJ and GCJ are very good actually, they just haven't reimplmented the entire standard library). Or IBM. Remember, the standards are open.
Next, the language is different from the programming approach. Use object-oriented thinking when it makes the most sense. Use procedural or functional programming when those make more sense. And then just pick the language based on where you see the project going and what features of the language you think will help. A java program is not necessarily object-oriented, it just provides the tools in case you are thinking that way while programming.
The purpose of capitalism is to channel various human behaviors, including the kind of aggression more appropriate to a shrieking, poop-flinging chimpanzee, into something that benefits society.
For many people, capitalism is about freedom more than any kind of social darwinism or whatever people like to think. For me, I value the following:
(1) If I produce something, I own exclusive rights to that product. (2) I own exclusive rights to the services that I can provide. (3) I can transfer those goods or services to other people at my option.
From those 3 principles, all of capitalism follows. I'm not saying there aren't problems (there are all kinds of problems, like who owns raw materials, is there a concept of "intellectual property", etc.). What I am saying is that for most seekers of capitalism, it's about freedoms, independence, and values.
It's also about mutually beneficial exchanges. principle #3 means that I won't transfer my good or service to you unless you transfer something more valuable to me (from my perspective). From that principle you get trade, which is (almost by definition) mutually beneficial. Almost all business is conducted in a mutually beneficial way.
Someone following the social-darwinism kind of thing that you're talking about is an extremest that has latched onto capitalism for some (probably unsuccessful) attempt to manipulate others.
A good product from a good company involves 3 things as far as I can tell:
(1) price (2) quality (3) matching the product with the customers who will benefit most
For instance, you may be able to get the best price on an expensive camera online: let's say $800 for a camera that might retail for $1200. That's a great price, and great quality.
However, maybe you don't have any use for the expensive lenses and myriad exposure options. Maybe you really needed a point-and-shoot camera with decent autosensing capabilities that can fit in your pocket.
If you go to a camera store, you might end up spending $500 for such a camera when you could get it online for $350. But that consumer still got a much better deal out of the camera store because it matched those 3 criteria better. Using your two criteria system, the consumer would end up with the $800 camera.
Often, marketing is seen in a very negative way. However, clearly there are very important situations in which it helps the consumer and the producer. Even with something like Coca Cola. Sure, I already know that it exists and that it tastes good. But maybe the commercial on TV shows it in an appetizing way, and allows me to anticipate enjoying it a few minutes later. Or maybe it just reminds me that I haven't had a Coke in a while, and that maybe I should buy a 12 pack an enjoy it over that week (I actually avoid soda usually, but occasionally a Coke can be really enjoyable).
So, marketing is valuable too. When it's targeted appropriately, that is. When it's not a targeted advertisement (maybe if a book club sees a beer advertisement), I can see how people get annoyed very quickly. Spam is probably the worst violater in this regard.
I really agree with your viewpoint. Hierarchies always break down after a certain point.
However, you can increase the possible size of a hierarchy by reducing the amount of control exerted by the central authority. The USSR broke down very quickly because they controlled every aspect of life. The US is working out better because our officials control fewer aspects of our lives.
Walmart has some important aspects of their business left up to individual store managers. For instance, the individual managers can control prices, inventory, and labor based on local supply, demand, and overhead costs.
The simple reason that there are no comparable open source implementations is that no open source developers have invested as much time to write the standard libraries. Let's not kid ourselves.
However, GCJ/GIJ are great. That project has made huge advances on an open implementation.
The prestigious "Best Database Solution" award went to EnterpriseDB this year. The press release is here.
EnterpriseDB is built upon the PostgreSQL database, and contributes what they create back to PostgreSQL (often immediately). One of the improvements they made to PostgreSQL is an Oracle compatibility layer.
PHP is blindingly simple. If you're coming into web programming from desktop programming, you already speak C, and PHP is like C with anything remotely complicated taken out.
"@" is a special character in PHP, used before a function call, to supress errors from being directly printed. That is about as un-simple as you can get in my opinion. There are all sorts of strange, inconsistent, or overly-specific aspects to the language. PHP is not even remotely like C, except for the { }.
I have never heard C being described as a particularly simple language
Well, it's simple in that you have a very limited set of data types and operators. Basically, you just have pointers, chars, ints, functions, and structs. And the operators are basically: add, mult, div, mod, subtract, dereference, function call. Everything else is in libraries, standard or otherwise. (This was not meant to be a formal exhaustive list, but a general characterization). So it's a minimalist language. I guess it's debatable whether that's "simple" or not.
To me, PHP is pretty complex. There are all sorts of implicit type conversions, special characters or sequences of characters that do very particular things like "?>", "<?", "`...`". There are arrays that can be sort of sequential and sort of associative at the same time. You can reset the type of a variable in place with settype, which can truncate a value. Pass-by-reference is entirely decided by the function definition. Errors are often printed directly rather than returning some kind of error code or throwing and exception. There's some really weird stuff too... like using "@" in front of a function call to supress errors from being sent to the output.
We may not be able to decide what is simple, but how 'bout we agree on what is not simple?
Slashdot Mirror
... and the government can't give away food that doesn't exist.
I may have misunderstood your point, but it seems you are looking at an RDBMS as merely a storage layer.
I look at an RDBMS as a system that is an integral part of the development process. Errors, constraints, warnings, user-defined types, procedures, and sometimes triggers are all there to aid in the development process. An RDBMS can abstract the data access by using views to separate logical representation and physical storage.
All the applications that access the same data set are able to use these facilities to develop rapidly without interfering with the other applications. The other applications may even be older versions of the same application.
The fact that a constraint isn't used after the application is "complete" is irrelevent if the application is never "complete".
If the entire system is perfectly specified from the beginning, and the code is well planned out, then you can engineer the storage layer as you describe. An RDBMS is for the people whose requirements are constantly evolving, and who make use of the development aid that an RDBMS provides.
If you're testing a new version of an application, and you get a constraint violation, or a type input error, or an RI violation, that is a godsend for debugging. You're happy it didn't corrupt the main data set, and you know exactly which application is causing the error, and when.
The MySQL client libraries are GPL, meaning that he can't link those libraries with his commercial application.
Normally client libraries are LGPL for a GPL product, but MySQL used GPL to be more restrictive.
PostgreSQL is great, and I encourage you to at least give it a try. Certainly write to the mailing lists with your experiences, particularly if you are having difficulty with something (see the pgsql-general list).
VACUUM is nothing to be scared of. In the upcoming 8.1 (currently in beta) you don't even need to think about it. It's basically just a command that tells PostgreSQL "Now's a good time to do some cleanup and maintenance work". Now, in 8.1, it automatically uses statistics to determine the best time to do that work, and how often.
Also, for the past few years, VACUUM is non-locking. That means that if PostgreSQL chooses to VACUUM just before a lot of activity starts, the VACUUM won't interfere with that activity.
In practice, VACUUM usually only causes a problem if you go a long time without VACUUMing. After a while, the planner can start to make bad choices, and the tables can get cluttered with dead tuples.
But, like I said, you don't need to know about this stuff because it's all automatic in 8.1.
The server does not care about "\q" at all. The server only accepts SQL queries.
"\q" is a command for the "psql" program (which is the command-line client that postgres admins usually use). When psql sees "\q" it terminates itself, which is just the client software. The server of course keeps running.
I haven't found MySQL to be too sensitive to crashes -- except once, in the case of a table with c.28M records and indices on several fields. This is used in a read-only application, being rebuilt from sources every quarter.
I think once counts as "too many" when talking about database crashes. I have never had an issue with PostgreSQL's reliability (however, Linux of course has issues, so sometimes the database server might have a problem with that).
I also wonder how MySQL would manage to corrupt itself when it's a read-only database.
Why on earth would you want your RDBMS vendor cramming their lousy procedural programming language down your throat?
If you have 10 applications accessing the same set of data, you may want the database to enforce constraints using procedural code.
If you try to do it client-side, than a bug in one application can cause failures in other applications. Unless, of course, you try to do huge amounts of data validation each and every time before you retrieve data.
If you do it client-side, it will most likely put more load on the database server, since a few stored procedures might be negligible compared with the application pulling in more data for processing, and possibly performaing extra joins. And the difference in the size of the client code will be huge.
Also, it's great to be able to separate physical layout from the view the applications have. Procedures are an important part of building the views, &c., that make that happen.
I agree in the sense that you don't want the database server running the application logic. But when it's closely tied to the data model, a few lines of well-placed code can make a huge difference.
I hate stored procedures
If you give up stored procedures/functions, you ALSO give up:
- user-defined types (isn't this important?)
- triggers
- functional indexes (how can you do without?!)
- functions that return a relation
- user-defined aggregates
- many types of data constraints
PLSQL which comes with Postgreqsl
The native procedural language that comes with PostgreSQL is called PL/pgSQL.
Also, PostgreSQL comes with several other server-side languages, and the mechanism is extensible (so anyone can add additional procedural languages at run time). Popular procedural languages include PL/perl, PL/java, and C.
but ALL dbms's are slightly different from eachother
MySQL is far away and completely alone in it's flavor of SQL and behavior. There are all kinds of strange things it does, like use the "`" to quote identifiers. Oracle, PostgreSQL, SQL Server, &c. all have their differences. But they all look a lot more like eachother than any of them look like MySQL.
The biggest and most 'incompatible' difference between postgres and mysql is the autoincrement field really, the rest is just small fish to fix.
Actually, the biggest differences are regarding types and constraints, in my opinion. For instance, MySQL thinks February 31st is a date, PostgreSQL does not. PostgreSQL enforces constraints, MySQL does not. MySQL NULL handling is non-standard.
How many times does the media report that the Global demand for grain has outstripped supply five years running
That sentence makes little or no sense. Unless of course governments are artificially reducing the price, in which case of course that will happen. The good news is that it's easily fixed: the governments involved just need to stop using price controls.
It seems kind of strange to me because the US artificially increases the price of grain.
A rational point, but I think you miss the point of a RDBMS. The point is that it's an extra abstraction layer above the filesystem, not that it provides more features.
The abstraction seperates physical data layout from the access layer. You can change the physical layout of the data for a second version of an application, and still let the first version see the data the way it always did. Two applications can see the same data in different ways. And you can prevent a buggy application from causing problems in other applications that access the same data by using constraints.
I'm getting out while MySQL is still portable to PG.
It's usually easier to go mysql->postgres than postgres->mysql (or for that matter, anything->mysql).
However, there are many incompatibilities. For some applications that type of migration can be quite a bit of work.
I don't care how good PostresSQL is, if it has people like you behind it I want no part of it.
Judging by the number of people who use that argument against PostgreSQL, I wouldn't be surprised at all if he were behind MySQL.
Heck, if MySQL's PR dept. can't come up with other compelling arguments, they might as well try reverse psychology.
It depends what you want to do with your project.
What depends? Are you answering his post or mine?
The downside is that my program runs much slower than if it had been written in C++.
It sounds almost certain that your application is I/O bound. I would guess that writing it in C++ would not see a performance improvement.
It's all about making money.
It's about making willing transactions with willing peers. And those transactions only take place when they benefit both parties. So, it's about making zillions of mutually-beneficial transactions.
It's a giant peer-to-peer economic system.
What do you think the term "convicted monopolist" means?
It means that we are no longer ruled by law, we are ruled by men. Anti-monopolist laws are subjective and unpredictible. The judge and the DOJ have all the power. It's not at all clear the point when someone transitions from a law-abiding citizen to a monopolist.
The rule of law is more important than whatever dumb reason they are attacking MS. It's not like they accomplished anything anyway, it's the "now what?" sydrome. They convicted MS, but they have no idea what to do about it.
So, what is the legal status of such projects ? Can Sun shut them down ? I'm not asking if it is profitable for Sun to do this, I'm asking if it is possible for them to do this ?
It's legal. It's just that Sun has made a sophisticated product very carefully with very high quality standards, and it is difficult for open source developers to match that in a fully-compatible way.
In short, is it safe to begin new projects in Java, or should I look into Ruby or something ? Or should I just stick to C and forget all about this current fad of object-orientation ?-)
Sun will be there, and Java will be there. And if not, some open product will likely suit your needs (GIJ and GCJ are very good actually, they just haven't reimplmented the entire standard library). Or IBM. Remember, the standards are open.
Next, the language is different from the programming approach. Use object-oriented thinking when it makes the most sense. Use procedural or functional programming when those make more sense. And then just pick the language based on where you see the project going and what features of the language you think will help. A java program is not necessarily object-oriented, it just provides the tools in case you are thinking that way while programming.
The purpose of capitalism is to channel various human behaviors, including the kind of aggression more appropriate to a shrieking, poop-flinging chimpanzee, into something that benefits society.
For many people, capitalism is about freedom more than any kind of social darwinism or whatever people like to think. For me, I value the following:
(1) If I produce something, I own exclusive rights to that product.
(2) I own exclusive rights to the services that I can provide.
(3) I can transfer those goods or services to other people at my option.
From those 3 principles, all of capitalism follows. I'm not saying there aren't problems (there are all kinds of problems, like who owns raw materials, is there a concept of "intellectual property", etc.). What I am saying is that for most seekers of capitalism, it's about freedoms, independence, and values.
It's also about mutually beneficial exchanges. principle #3 means that I won't transfer my good or service to you unless you transfer something more valuable to me (from my perspective). From that principle you get trade, which is (almost by definition) mutually beneficial. Almost all business is conducted in a mutually beneficial way.
Someone following the social-darwinism kind of thing that you're talking about is an extremest that has latched onto capitalism for some (probably unsuccessful) attempt to manipulate others.
A good product from a good company involves 3 things as far as I can tell:
(1) price
(2) quality
(3) matching the product with the customers who will benefit most
For instance, you may be able to get the best price on an expensive camera online: let's say $800 for a camera that might retail for $1200. That's a great price, and great quality.
However, maybe you don't have any use for the expensive lenses and myriad exposure options. Maybe you really needed a point-and-shoot camera with decent autosensing capabilities that can fit in your pocket.
If you go to a camera store, you might end up spending $500 for such a camera when you could get it online for $350. But that consumer still got a much better deal out of the camera store because it matched those 3 criteria better. Using your two criteria system, the consumer would end up with the $800 camera.
Often, marketing is seen in a very negative way. However, clearly there are very important situations in which it helps the consumer and the producer. Even with something like Coca Cola. Sure, I already know that it exists and that it tastes good. But maybe the commercial on TV shows it in an appetizing way, and allows me to anticipate enjoying it a few minutes later. Or maybe it just reminds me that I haven't had a Coke in a while, and that maybe I should buy a 12 pack an enjoy it over that week (I actually avoid soda usually, but occasionally a Coke can be really enjoyable).
So, marketing is valuable too. When it's targeted appropriately, that is. When it's not a targeted advertisement (maybe if a book club sees a beer advertisement), I can see how people get annoyed very quickly. Spam is probably the worst violater in this regard.
I really agree with your viewpoint. Hierarchies always break down after a certain point.
However, you can increase the possible size of a hierarchy by reducing the amount of control exerted by the central authority. The USSR broke down very quickly because they controlled every aspect of life. The US is working out better because our officials control fewer aspects of our lives.
Walmart has some important aspects of their business left up to individual store managers. For instance, the individual managers can control prices, inventory, and labor based on local supply, demand, and overhead costs.
If it were an open standard...
It is an open standard!
The simple reason that there are no comparable open source implementations is that no open source developers have invested as much time to write the standard libraries. Let's not kid ourselves.
However, GCJ/GIJ are great. That project has made huge advances on an open implementation.
The prestigious "Best Database Solution" award went to EnterpriseDB this year. The press release is here.
EnterpriseDB is built upon the PostgreSQL database, and contributes what they create back to PostgreSQL (often immediately). One of the improvements they made to PostgreSQL is an Oracle compatibility layer.
They competed against MySQL, Oracle, and IBM DB2.
PHP is blindingly simple. If you're coming into web programming from desktop programming, you already speak C, and PHP is like C with anything remotely complicated taken out.
"@" is a special character in PHP, used before a function call, to supress errors from being directly printed. That is about as un-simple as you can get in my opinion. There are all sorts of strange, inconsistent, or overly-specific aspects to the language. PHP is not even remotely like C, except for the { }.
I have never heard C being described as a particularly simple language
Well, it's simple in that you have a very limited set of data types and operators. Basically, you just have pointers, chars, ints, functions, and structs. And the operators are basically: add, mult, div, mod, subtract, dereference, function call. Everything else is in libraries, standard or otherwise. (This was not meant to be a formal exhaustive list, but a general characterization). So it's a minimalist language. I guess it's debatable whether that's "simple" or not.
To me, PHP is pretty complex. There are all sorts of implicit type conversions, special characters or sequences of characters that do very particular things like "?>", "<?", "`...`". There are arrays that can be sort of sequential and sort of associative at the same time. You can reset the type of a variable in place with settype, which can truncate a value. Pass-by-reference is entirely decided by the function definition. Errors are often printed directly rather than returning some kind of error code or throwing and exception. There's some really weird stuff too... like using "@" in front of a function call to supress errors from being sent to the output.
We may not be able to decide what is simple, but how 'bout we agree on what is not simple?