The biochemistry of anaerobic conversion of sugars into alcohol and carbon dioxide produces a fixed ratio of alcohol to carbon dioxide, independent of the yeast strain.
Can you cite your source? What you say sounds plausible, but it also sounds plausible to me that breaking down larger chains into simple sugars might produce a different ratio.
I am pretty sure that that MySQL still has better client slave replication
It depends on what you mean by "better".
Slony-I is a good asynchronous master/slave replication system for PostgreSQL. It takes a lot of effort to administer, but it is also very flexible, and supports some very sophisticated features like:
* cascading replication (e.g. slave sends data down to other slaves)
* per-table replication so that some nodes can be master for some tables and others can be master for other tables.
* can replicate between different versions of PostgreSQL
And the ".ORG" in "slashdot.ORG" uses PostgreSQL, and Slony-I, the last time I checked anyway.
The forking of MySQL is going to split resources and creating that replacement for InnoDB may take longer.
Just to clarify: InnoDB is GPL.
A fork is still non-trivial business. Trying to do actually accomplish anything requires a lot of organization and talent. And in the interim, you have a problem where there are:
* multiple forks of MySQL
* multiple storage engines
* multiple forks of a single storage engine: InnoDB
That makes QA, support, and usability a nightmare. It would take a very strong leader to really bring it all together into a single product again.
I doubt that the internally-released version of MySQL on non-windows platforms was so amazingly successful that PostgreSQL felt a need to copy the name.
More likely, it's because PostgreSQL just started supporting SQL, and they wanted the name to appear for anyone searching for a SQL DBMS by typing in "SQL".
* The pieces fit together more seamlessly. With MySQL, there are weird exceptions like "you can't use full text search with InnoDB".
* More developer friendly: many nice, rich data types, offering multiple languages to write functions in, consistent and predictable behavior (few surprises)
* Very extensible -- if you have an idea, it can probably be done without recompiling or even stopping the server. Even if you don't want to do it yourself, maybe someone else has (cf. PostGIS extension).
* transactional DDL -- you don't know what you're missing until you have this. You can begin a transaction, rename a table, make a new table in it's place and populate it with data, and commit -- all without taking the application down! And if you have a problem halfway through, just ROLLBACK.
* I think it's a little more welcoming to developers. You can write a function in perl as a humble user and the statements you issue inside it will follow ACID semantics right along with the rest of the transaction outside the function. Or, if you're superuser, go ahead and open a socket connection and go crazy. PostgreSQL isn't afraid of your code.
However, MySQL is still strong in a couple areas:
* simple replication
* in-place upgrades
* If you really know MySQL well, you can probably avoid many of its pitfalls and make it do what you want. This isn't really a strength, and it's not 100% true, but take this as a mitigating factor to anyone who complains about MySQL.
Except he's a public official. I for one very much doubt he did this in his own time,...
Representatives don't have all that many duties. They can pretty much spend their time however they please, as long as it's legal.
or with his own money.
If you are suggesting he illegally misappropriated tax dollars or public resources for a personal matter, that is a serious accusation. Please substantiate it.
If the Supreme Court says that the right to privacy is a basic right, they don't have to justify it as an extension of the 4th.
Let's say that there's a "right to privacy" that is protected by the 9th (I neither agree nor disagree with this assertion, because it's fairly vague).
What does a "right" mean in the context of the Constitution? It's some limitation on the power of the federal government (and in many cases the state governments, as well). It may be that they can't punish you for something (free speech, keeping a firearm), or that they cannot do something (unreasonable search, cruel punishment).
So how would such a right to privacy actually function? Surely a constitutional right does not limit the power of a citizen; that's what laws are for. And the representative is a citizen. So as long as the representative did not use powers granted to him by the federal government in order to breach the privacy, it's perfectly allowable.
How can you assume data integrity is going to suck by storing data in multiple places?
You're right, but I think there's some confusion here still.
Normalization is about organizing base relation variables so that many common constraints (e.g. functional dependencies) can be enforced within an individual relation variable via keys.
This helps avoid "update anomalies" where, in order to maintain a consistent database, you must update several relation variables at once. Update anomalies can compromise the logical integrity of a database if all the constraints are not still strictly enforced by some other means (e.g. a triggered procedure and careful locking).
You can physically store the data as many places as you want, to ensure physical integrity. That makes perfect sense.
So physical integrity is orthogonal to logical consistency. Storage is entirely physical, while normalization (and other forms of organization) are entirely logical.
huge data warehouse that hasn't normalized status codes
What do status codes have to do with database normalization? Database normalization begins with the assumption that you've already decided upon all the constraints your data must satisfy, including type constraints.
Huh? There are plenty of remote places with fertile soil that can be had for almost no money at all. People happen to like living around lots of other people, and there are a lot of economic benefits to doing so.
Of course luck was involved. But you could have given a million people the same set of opportunities, and none of them would have made what Bill Gates did.
Going through a Ph.D. program when you are in your 20s isn't working hard.
Hard work isn't just a matter of making yourself tired and then feeling that you deserve something as a result of being tired.
Hard work may mean staying up studying, not drinking too much, postponing child rearing, seeking out people that you can learn from, earning trust and reputation, working when nobody is telling you to work, and making other good decisions.
The best ways to a life of comfort and excitement are luck, corruption, parental privilege, or a combination of all three.
You forgot the most important one: good decisions.
Almost everyone in life is faced with a choice: when do you have children?
If you choose age 15, then you are (statistically) in for a life of hard work and sacrifice, without a lot of comfort or excitement.
If you choose age 25, you are much more likely to be comfortable and have opportunity for excitement.
That choice is neither luck, corruption, or parental privilege, but it matters greatly. There are all kinds of decisions like that:
* do you take a night class after work, or do you come home and drink beer and watch TV?
* do you take the challenging courses in school, or do you spend your time at parties or making trouble?
* what friends do you choose to spend time with?
* are you resourceful enough to seek out opportunity when it is not immediately presented to you? For example, moving to another city with more jobs?
Your viewpoint is extremely cynical. There is still a lot of opportunity in the U.S. for self-determination. It usually takes a combination of all of these things to make someone poor: a series of bad choices, some bad luck, and their family isn't rich enough to bail them out.
there is no real scarcity of food, shelter and health care
Unfortunately, there still is, and that's a fact of life for at least the near future. Ask anyone waiting in line for a doctor, or anyone that lives 30+ miles from work, or anyone in a remote village in Africa where delivery of food is extremely expensive.
simply a miss [sic] allocation of resources.
Allocating resources is a non-trivial problem, and not something that can be solved by a benevolent group of bureaucrats.
"relational algebra" way (individual statements correlated by procedure code)
Relational Algebra is not procedural or imperative. Any Relational Calculus expression can be written as a logically-equivalent Relational Algebra expression, and vice versa.
And they can both be optimized into whatever procedure will execute fastest on a given machine.
Otherwise, it's just fancy regurgitation of facts using a complex language parser.
It's more than regurgitation. It can make inferences from the set of facts available to generate new propositions. Some of these new propositions may not be obvious to a human looking at the same set of source facts.
I don't have the 2006 standard; I didn't even know they released anything that year. 2003 standard says:
A table check constraint is satisfied if and only if the specified <search condition> is not False...
in section 4.17.3.
NULL is not the same as FALSE, so unless the standard itself uses multi-valued logic, I believe my claim still holds.
And really, I didn't mean to jump into the details and start citing the standard. We could talk all day about the implications. My primary point is the following:
A lot of intelligent, analytical people who have been around NULL for a long time still fail to really understand it*. How can these people -- who are driving the reports upon which business relies -- really have confidence that they are getting the correct answers when NULLs appear at every turn**? SQL NULL is an unmitigated disaster.
In other languages, C/Java NULL, Ruby nil, Python None, etc., all have the nice property that they throw an error quickly. SQL seems to think it can make sense from nonsense, and that's bound to result in wrong answers.
*: In no way at all do I think I'm smarter than the people in this thread who got NULL completely wrong, I just decided to dig at this particular issue for a while.
**: NULLs appear even if your tables don't store any NULLs at all. For instance, in an outer join, or as the result of an aggregate (other than a couple exceptions) with no input tuples.
He sure sounded like he understood SQL NULL, anyway. Did you consider testing his claims?
See my reply to him for further information.
Or, see the SQL standard 2008 "Part 2: Foundation" (SQL/Foundation) section 4.5.2:
...any comparison involving the null value or an Unknown truth value will return an Unknown result.
And "NOT Unknown" is defined to be Unknown (see 6.34: General Rules: 2).
These are clear contradictions to the idea that NULL is false, or that the original statement in question is false. NOT FALSE is clearly TRUE, which shows that the statement does not evaluate to FALSE, because if you put a NOT in front of it, it's still unknown.
The fact that a variety of highly analytical people in this thread are getting this wrong (after NULL has been ubiquitous for ages) is strong evidence that SQL NULL is a disaster. Keep in mind that this is not in any way an insult to anyone in this thread: the fact that you have misconceptions about NULL is probably a good sign.
No, it does not. Get rid of the WHERE, and try it in a CHECK constraint, and it will never fail.
Your claim that the statement evaluates to false does not make any sense at all. Try the exact same thing with a NOT in front of it: if it were really FALSE, NOT FALSE would be TRUE. But it's still NULL, and then the WHERE clause treats it as FALSE-like.
As consolation, your logic is at least as good as the logic of the people who implemented SQL NULL.
It's a bit weird, but it makes sense when you actually follow the logic.
Not really.
The expression "0 <> 1" is true, but the poster you referenced also says "0 <> NULL", which is NOT true, it is NULL.
Additionally, NULL is not always treated as false-like. For instance, if you added the constraint "CHECK (0 NOT IN (NULL, 1))", that would always succeed, as though it was "CHECK(true)".
And if you think "it makes sense", consider this:... WHERE x > 0 OR x <= 0 If x is NULL, that statement will evaluate to NULL, and then be treated as false-like, and the row will not be returned. However, there is no possible value of x such that the statement will be false.
I'm not a big fan of NULL, but I think the most obvious sign that it's a problem is that so many people think they understand it, when they do not.
At some point, primary care physicians should be put on fixed salaries
That is not a magic bullet. One of the obvious questions is how do you differentiate between a doctor that's willing to work 70 hours a week, and make house calls, from one willing to work 40 hours per week that only works from the office?
Maybe fixed salaries are useful for large institutions, where they tell you exactly how many hours to work, and they pretty much make doctors into commodities.
I think that the solution is to allow both -- like we have now. If a patient wants institutional, relatively bureaucratic care from a doctor with no strong financial incentives (good or bad), they go to such an institution. If they want personalized care from someone with stronger financial incentives (good and bad), they go to a private practice or similar.
That is a powerful claim. You did not provide anywhere near enough evidence to back it up.
For instance, how do you convince a garbage man to do his job? Few people can be intrinsically motivated to do something like that. Even if they have a strong work ethic, they may find other things like farming or construction work much more intrinsically motivating.
Even assuming that people can be intrinsically motivated to do anything, somehow society must get people to do the right amount of the right things. We don't need 40 million electricians in the US, for instance.
You seem to think controlling our emissions means turning off civilization.
I didn't say that. I even questioned how many things we should stop doing, and at what cost.
EVERY coal fired plant in existance today will need to be replaced within the next 4-5 decades
Replacing coal with nuclear is probably a reasonable cost that could be justified, so stopping most coal in the US would probably be reasonable. However, replacing all coal everywhere is probably just not going to happen, even in 50 years.
So, I think a reasonable response to my question "how many things should we stop" would be "most of the western world's use of coal". I'm sure the cost could even be estimated with some accuracy, and I wouldn't be shocked if it were very low or even negative.
Slashdot Mirror
They are about to become part of a company that is, undeniably, bad for America.
Saying IBM is "undeniably" bad for America is a pretty strong statement. Care to back it up?
The biochemistry of anaerobic conversion of sugars into alcohol and carbon dioxide produces a fixed ratio of alcohol to carbon dioxide, independent of the yeast strain.
Can you cite your source? What you say sounds plausible, but it also sounds plausible to me that breaking down larger chains into simple sugars might produce a different ratio.
I am pretty sure that that MySQL still has better client slave replication
It depends on what you mean by "better".
Slony-I is a good asynchronous master/slave replication system for PostgreSQL. It takes a lot of effort to administer, but it is also very flexible, and supports some very sophisticated features like:
* cascading replication (e.g. slave sends data down to other slaves)
* per-table replication so that some nodes can be master for some tables and others can be master for other tables.
* can replicate between different versions of PostgreSQL
And the ".ORG" in "slashdot.ORG" uses PostgreSQL, and Slony-I, the last time I checked anyway.
The forking of MySQL is going to split resources and creating that replacement for InnoDB may take longer.
Just to clarify: InnoDB is GPL.
A fork is still non-trivial business. Trying to do actually accomplish anything requires a lot of organization and talent. And in the interim, you have a problem where there are:
* multiple forks of MySQL
* multiple storage engines
* multiple forks of a single storage engine: InnoDB
That makes QA, support, and usability a nightmare. It would take a very strong leader to really bring it all together into a single product again.
I refuse to use the new name PostgreSQL
which is a cheap cop out and attempt to leverage
on the success of MySQL by copying the idea of
the name
The project changed the name to PostgreSQL in 1996:
http://www.postgresql.org/docs/8.3/static/history.html
-- http://en.wikipedia.org/wiki/MySQL
I doubt that the internally-released version of MySQL on non-windows platforms was so amazingly successful that PostgreSQL felt a need to copy the name.
More likely, it's because PostgreSQL just started supporting SQL, and they wanted the name to appear for anyone searching for a SQL DBMS by typing in "SQL".
Trying to be as objective as possible:
* The pieces fit together more seamlessly. With MySQL, there are weird exceptions like "you can't use full text search with InnoDB".
* More developer friendly: many nice, rich data types, offering multiple languages to write functions in, consistent and predictable behavior (few surprises)
* Very extensible -- if you have an idea, it can probably be done without recompiling or even stopping the server. Even if you don't want to do it yourself, maybe someone else has (cf. PostGIS extension).
* transactional DDL -- you don't know what you're missing until you have this. You can begin a transaction, rename a table, make a new table in it's place and populate it with data, and commit -- all without taking the application down! And if you have a problem halfway through, just ROLLBACK.
* I think it's a little more welcoming to developers. You can write a function in perl as a humble user and the statements you issue inside it will follow ACID semantics right along with the rest of the transaction outside the function. Or, if you're superuser, go ahead and open a socket connection and go crazy. PostgreSQL isn't afraid of your code.
However, MySQL is still strong in a couple areas:
* simple replication
* in-place upgrades
* If you really know MySQL well, you can probably avoid many of its pitfalls and make it do what you want. This isn't really a strength, and it's not 100% true, but take this as a mitigating factor to anyone who complains about MySQL.
Except he's a public official. I for one very much doubt he did this in his own time,...
Representatives don't have all that many duties. They can pretty much spend their time however they please, as long as it's legal.
or with his own money.
If you are suggesting he illegally misappropriated tax dollars or public resources for a personal matter, that is a serious accusation. Please substantiate it.
If the Supreme Court says that the right to privacy is a basic right, they don't have to justify it as an extension of the 4th.
Let's say that there's a "right to privacy" that is protected by the 9th (I neither agree nor disagree with this assertion, because it's fairly vague).
What does a "right" mean in the context of the Constitution? It's some limitation on the power of the federal government (and in many cases the state governments, as well). It may be that they can't punish you for something (free speech, keeping a firearm), or that they cannot do something (unreasonable search, cruel punishment).
So how would such a right to privacy actually function? Surely a constitutional right does not limit the power of a citizen; that's what laws are for. And the representative is a citizen. So as long as the representative did not use powers granted to him by the federal government in order to breach the privacy, it's perfectly allowable.
How can you assume data integrity is going to suck by storing data in multiple places?
You're right, but I think there's some confusion here still.
Normalization is about organizing base relation variables so that many common constraints (e.g. functional dependencies) can be enforced within an individual relation variable via keys.
This helps avoid "update anomalies" where, in order to maintain a consistent database, you must update several relation variables at once. Update anomalies can compromise the logical integrity of a database if all the constraints are not still strictly enforced by some other means (e.g. a triggered procedure and careful locking).
You can physically store the data as many places as you want, to ensure physical integrity. That makes perfect sense.
So physical integrity is orthogonal to logical consistency. Storage is entirely physical, while normalization (and other forms of organization) are entirely logical.
huge data warehouse that hasn't normalized status codes
What do status codes have to do with database normalization? Database normalization begins with the assumption that you've already decided upon all the constraints your data must satisfy, including type constraints.
Huh? There are plenty of remote places with fertile soil that can be had for almost no money at all. People happen to like living around lots of other people, and there are a lot of economic benefits to doing so.
Of course luck was involved. But you could have given a million people the same set of opportunities, and none of them would have made what Bill Gates did.
Going through a Ph.D. program when you are in your 20s isn't working hard.
Hard work isn't just a matter of making yourself tired and then feeling that you deserve something as a result of being tired.
Hard work may mean staying up studying, not drinking too much, postponing child rearing, seeking out people that you can learn from, earning trust and reputation, working when nobody is telling you to work, and making other good decisions.
The best ways to a life of comfort and excitement are luck, corruption, parental privilege, or a combination of all three.
You forgot the most important one: good decisions.
Almost everyone in life is faced with a choice: when do you have children?
If you choose age 15, then you are (statistically) in for a life of hard work and sacrifice, without a lot of comfort or excitement.
If you choose age 25, you are much more likely to be comfortable and have opportunity for excitement.
That choice is neither luck, corruption, or parental privilege, but it matters greatly. There are all kinds of decisions like that:
* do you take a night class after work, or do you come home and drink beer and watch TV?
* do you take the challenging courses in school, or do you spend your time at parties or making trouble?
* what friends do you choose to spend time with?
* are you resourceful enough to seek out opportunity when it is not immediately presented to you? For example, moving to another city with more jobs?
Your viewpoint is extremely cynical. There is still a lot of opportunity in the U.S. for self-determination. It usually takes a combination of all of these things to make someone poor: a series of bad choices, some bad luck, and their family isn't rich enough to bail them out.
there is no real scarcity of food, shelter and health care
Unfortunately, there still is, and that's a fact of life for at least the near future. Ask anyone waiting in line for a doctor, or anyone that lives 30+ miles from work, or anyone in a remote village in Africa where delivery of food is extremely expensive.
simply a miss [sic] allocation of resources.
Allocating resources is a non-trivial problem, and not something that can be solved by a benevolent group of bureaucrats.
"relational algebra" way (individual statements correlated by procedure code)
Relational Algebra is not procedural or imperative. Any Relational Calculus expression can be written as a logically-equivalent Relational Algebra expression, and vice versa.
And they can both be optimized into whatever procedure will execute fastest on a given machine.
Otherwise, it's just fancy regurgitation of facts using a complex language parser.
It's more than regurgitation. It can make inferences from the set of facts available to generate new propositions. Some of these new propositions may not be obvious to a human looking at the same set of source facts.
*shrug*
I don't have the 2006 standard; I didn't even know they released anything that year. 2003 standard says:
in section 4.17.3.
NULL is not the same as FALSE, so unless the standard itself uses multi-valued logic, I believe my claim still holds.
And really, I didn't mean to jump into the details and start citing the standard. We could talk all day about the implications. My primary point is the following:
A lot of intelligent, analytical people who have been around NULL for a long time still fail to really understand it*. How can these people -- who are driving the reports upon which business relies -- really have confidence that they are getting the correct answers when NULLs appear at every turn**? SQL NULL is an unmitigated disaster.
In other languages, C/Java NULL, Ruby nil, Python None, etc., all have the nice property that they throw an error quickly. SQL seems to think it can make sense from nonsense, and that's bound to result in wrong answers.
*: In no way at all do I think I'm smarter than the people in this thread who got NULL completely wrong, I just decided to dig at this particular issue for a while.
**: NULLs appear even if your tables don't store any NULLs at all. For instance, in an outer join, or as the result of an aggregate (other than a couple exceptions) with no input tuples.
"try it in a CHECK constraint, and it will never fail"
While I have the standard open, here's a reference to back up my claim above:
-- SQL 2008 Part 2: Foundation (SQL/Foundation) section 4.17.2
And I also tried it in PostgreSQL, which generally has respect for the standard.
So, a constraint does, indeed, treat NULL as TRUE-like.
He sure sounded like he understood SQL NULL, anyway. Did you consider testing his claims?
See my reply to him for further information.
Or, see the SQL standard 2008 "Part 2: Foundation" (SQL/Foundation) section 4.5.2:
And "NOT Unknown" is defined to be Unknown (see 6.34: General Rules: 2).
These are clear contradictions to the idea that NULL is false, or that the original statement in question is false. NOT FALSE is clearly TRUE, which shows that the statement does not evaluate to FALSE, because if you put a NOT in front of it, it's still unknown.
The fact that a variety of highly analytical people in this thread are getting this wrong (after NULL has been ubiquitous for ages) is strong evidence that SQL NULL is a disaster. Keep in mind that this is not in any way an insult to anyone in this thread: the fact that you have misconceptions about NULL is probably a good sign.
"If x is NULL, the statement evaluates to false."
No, it does not. Get rid of the WHERE, and try it in a CHECK constraint, and it will never fail.
Your claim that the statement evaluates to false does not make any sense at all. Try the exact same thing with a NOT in front of it: if it were really FALSE, NOT FALSE would be TRUE. But it's still NULL, and then the WHERE clause treats it as FALSE-like.
As consolation, your logic is at least as good as the logic of the people who implemented SQL NULL.
It's a bit weird, but it makes sense when you actually follow the logic.
Not really.
The expression "0 <> 1" is true, but the poster you referenced also says "0 <> NULL", which is NOT true, it is NULL.
Additionally, NULL is not always treated as false-like. For instance, if you added the constraint "CHECK (0 NOT IN (NULL, 1))", that would always succeed, as though it was "CHECK(true)".
And if you think "it makes sense", consider this: ... WHERE x > 0 OR x <= 0
If x is NULL, that statement will evaluate to NULL, and then be treated as false-like, and the row will not be returned. However, there is no possible value of x such that the statement will be false.
I'm not a big fan of NULL, but I think the most obvious sign that it's a problem is that so many people think they understand it, when they do not.
At some point, primary care physicians should be put on fixed salaries
That is not a magic bullet. One of the obvious questions is how do you differentiate between a doctor that's willing to work 70 hours a week, and make house calls, from one willing to work 40 hours per week that only works from the office?
Maybe fixed salaries are useful for large institutions, where they tell you exactly how many hours to work, and they pretty much make doctors into commodities.
I think that the solution is to allow both -- like we have now. If a patient wants institutional, relatively bureaucratic care from a doctor with no strong financial incentives (good or bad), they go to such an institution. If they want personalized care from someone with stronger financial incentives (good and bad), they go to a private practice or similar.
However, incentives don't work
That is a powerful claim. You did not provide anywhere near enough evidence to back it up.
For instance, how do you convince a garbage man to do his job? Few people can be intrinsically motivated to do something like that. Even if they have a strong work ethic, they may find other things like farming or construction work much more intrinsically motivating.
Even assuming that people can be intrinsically motivated to do anything, somehow society must get people to do the right amount of the right things. We don't need 40 million electricians in the US, for instance.
You seem to think controlling our emissions means turning off civilization.
I didn't say that. I even questioned how many things we should stop doing, and at what cost.
EVERY coal fired plant in existance today will need to be replaced within the next 4-5 decades
Replacing coal with nuclear is probably a reasonable cost that could be justified, so stopping most coal in the US would probably be reasonable. However, replacing all coal everywhere is probably just not going to happen, even in 50 years.
So, I think a reasonable response to my question "how many things should we stop" would be "most of the western world's use of coal". I'm sure the cost could even be estimated with some accuracy, and I wouldn't be shocked if it were very low or even negative.
a clear and present danger
That's hyperbole.