So you basically want incontrovertible proof that this passage hasn't been open in 400 years?
Nope, the article is what proclaimed that this is the first time in history for this kind of event. I just want some supporting data more than "a few explorers we sent didn't make it" to justify the article's claim. It is entirely unreasonable to make such a claim based on a few voyages. It may be true, the the article didn't say "may be".
Do you have some more convincing data than the article provided? If so, I'd like to see it.
but that does not mean you discount all observations less than infinite.
I'm not discounting them. How many are there? A few expeditions? Is that really enough to suggest that the passage was closed for a long period of time without interruption? There isn't even one expedition per year, so that leaves lots of huge holes in the claim.
I am very willing to accept the data. I just don't think it's a reasonable logical step to go from:
"A few expeditions failed" to "the passage must have been closed since at least the first expedition".
but your reasoning is a tired, specious
You are the one using specious reasoning. A few expeditions failed, so it must have been closed the entire time (except, of course, in 1903)?
If they really want to help Python, build some online documentation that [isn't bad]
There are a few under-documented libraries that I've run into before, but largely I've been happy with the python docs.
I could swear you were talking about Ruby, because that's exactly the way I feel about Ruby (a language I love, but the docs are disorganized, decentralized, and generally poor).
What if it opens up on an annual basis? Will you then acknowledge that this is at least unprecedented in the last 400+ years?
Only if the historical data is sufficient to say that, over the last 400 years, there have not been 2 consecutive years that it's been open. I don't think a few [dozen] explorers proves that, either.
Actually, there is data going back thousands of years in the form of ice cores -- or there used to be. Of course, these haven't been done along the entire passage
If you have a fairly good sampling of carbon-dated ice cores from areas that are likely to be the first to melt, I'd accept that as good data. It would be quite convincing that the passage was closed if you said "there was a big sheet of 5000 year old ice blocking the passage, until this year".
A very large number of relatively rich people in CA does drive up the median.
The reason median is a useful statistic is because it represents an "average" (you might say "typical") player within the group. If your argument is that a "typical" Californian home purchaser paid $200k, then I think the median of ~$450k refutes that.
You seem to be measuring in kind of a strange way (not wrong, just not a number that most people deal with). What it seems to me that you mean is: if you throw a dart at a map of California, and buy an house on an acre there, how much will it cost? If that's the question you're asking, I'm willing to believe your numbers.
Did you happen to notice that one of those attempts was successful in 1903?
My point is that when people see a headline about the first time "in history," they aren't thinking 30 years, they are thinking 3000 years. But 30 years is all we have any good data about at all. The fact that previous attempts failed does not mean that the passage did not exist previously, there are many plausible explanations, such as:
(1) they went at the wrong time of year (2) they went the wrong year (3) they couldn't find/navigate the route
We now have satellites, so we can see whether it exists or not, year-round. That's a much better tool than "we sent a few explorers, and they didn't make it, therefore the passage does not exist."
You accuse me of fear, uncertainty, and doubt. But it's hard to buy into this global warming hysteria (I believe some of the claims, it's just the hysteria that I don't buy) when publishers continue to sensationalize headlines. Then you come along and pretend that a few explorers going there on a few occasions proves something about the existence over a long period of time. It doesn't. There is simply no good data about that general area to support the claim that it was impassible for 400 years straight until 2007; and there's certainly no good data to support the claim that it was impassible for the thousands of years straight until 2007. I know the article didn't make that claim directly, but that's what someone reading the headline is lead to believe, so it is deceptive even if it might not be technically dishonest.
If its never been passable before why was it called a passage?
It seems as though the article defines "history" to be the last 30 years, since we've had satellites monitoring it. Doesn't seem nearly as amazing to me. I'm sure the people who published the article knew that they were being deceptive at the time (even if they are technically correct), but real headlines don't cause the hysteria they are seeking.
before [OpenBSD] destroys any ounce of credibility it still has.
The developers of, among many other achievements, OpenSSH, have more than an ounce of credibility. Any attempt to marginalize a group that's produced such a vital, omnipresent contribution is an attempt to rewrite history.
We should remember that security is hard and that to produce secure software requires not just the will but also rare ability.
Your other criticisms may be valid, but we should remember who we're talking about here. Security experts are among the most difficult developers to replace. There's a reason that we're talking about OpenBSD on slashdot right now: the viability of the project could have an impact on many people.
I don't see how you can say that an acre or two and a big house for $200k is representative of California with median home prices what they are. I certainly don't think it's representative of the people in California.
Its because making it big is 99% luck and less than 1% hard work.
Of course those people had some great opportunities that are very rare -- even among the rich.
The reason these guys are successful is because you could give those same exact set of opportunities to a million people, and none of them would make anything out of those opportunities. It might be too risky for their tastes, or they might not be comfortable working 80 hour weeks when it really counts. Or, they might not realize how lucky they are, and wait for the next once-in-a-lifetime opportunity to come along.
Anywhere outside of the few largest cities (eg. the greater Los Angeles and San Francisco area), and 200K will easily buy you a big house and an acre or perhaps two
I suggest you look around to see what $200k will buy you in California. If you are within two hours of either of those places, get prepared to pay a lot more than that for "a big house and an acre or perhaps two". Same if you are anywhere near the coast.
You should be thinking more along the lines of $300k for a tract home, unless you go to some fairly remote areas.
It's quite likely that your ancestors didn't enter this nation legally either.
In the US, you aren't punished for someone else's unlawful acts.
Marrying for the sake of citizenship
That's not a "trick", that's following the law.
American laws have always been xenophobic to varying degrees
Laws don't fear, people do.
Our laws have always been somewhat xenophobic for a nation that prides itself as a melting pot
How is giving an advantage to one group, Mexicans, at the expense of other groups, like Asians, helping us become a better melting pot? Being opposed to illegal immigration does not mean I'm opposed to immigration. I oppose the current policies, which shift the balance heavily in the favor of illegal Mexican immigrants at the expense of all others. We should, as a nation, be able to decide who gets in and who doesn't, and to conduct the immigration process in an orderly way.
Illegal immigration is an administrative violation
Should we have immigration laws, or should we have no immigration laws at all? This question is not rhetorical, but an important question that few illegal immigration advocates will answer.
I believe that they are important. Because of that, I believe they should be enforced. I don't care what level of violation it is, if it's important, the laws on the books should be enforced using the limited powers of the government. That is called "The Rule of Law," and it is one of the most important aspects of Western society, in my opinion.
My point had nothing to do with adherence to the SQL standard (although in my opinion, MySQL's default behavior is further away than other databases). My point was that changing the storage engine (the physical storage mechanism) changes the semantic behavior of commands. MyISAM behaves differently than InnoDB, and you might need to change your application code if you want to change storage engines.
I'm about to do some really, really big archiving projects,... Break it, Break it, Break it, get it right.
I don't envy that task;)
With a topic like databases, there are a million people pulling in different directions and they have different perspectives -- and different business incentives. There are two things that always work to get to the bottom of any discussion super-saturated with opinion:
(1) Try to understand a lot of perspectives. (2) Look for people who have a very good grasp of logic, a lot of knowledge, and a good reputation, and learn some fundamentals from them. When you do this, you can cut through 90% of the crap in no time.
I personally recommend reading anything by C.J. Date. He's a leader in relational theory, he's very logical, and has a writing style that works for me. It took me a while to appreciate a lot of his ideas, however. It might not help on your current project, except perhaps giving some hints on best practices (assuming that you buy into his arguments). Note: I own 4 of his books, so I'm probably violating rule #1, so whatever you do, don't consider me a member of group #2:)
surrogate keys you're talking about -- which are technically a design flaw (or perhaps a "design smell" to crib an XP term), but they're kind of unavoidable for efficiency (I sure as hell don't want to sling around whole arrays of street/city/state/post in my CRM app)
If by "efficiency" you mean performance, the surrogate keys are a physical implementation detail and should be hidden from the application, in which case you don't have any surrogate keys at all.
If by "efficiency" you mean that you prefer to deal with data by assigning new logical names (e.g. an employee ID) that the application/user actually care about, then that's not a surrogate key either, but a real key. Even though my driver's license number is generated, I still know what it is, and still may need to identify myself by that number in some situations. So it's not a surrogate key.
A surrogate key is when you start muddying the distinction between the logical and physical layers. A surrogate key is something that appears in the logical layer but has absolutely no meaning to anything outside the database. Why present something at the logical level that is meaningless at the logical level? It's essentially like the database spitting out physical addresses to the application code ("INSERT successful, record stored on block number 1234 on volume 4576, and it was also at memory address 0x12345678 for a while...).
Products like MySQL seem to get along just fine supporting multiple options for storage engine.
Except that in MySQL, changing the storage engine means that it will not "still be SQL" it will be a different variant of SQL, with different features available and different semantics. The storage engines aren't independent of the logical level. That is one of the biggest failings of MySQL.
From a standard 3rd generation programing language one can read and write into flat files and we can do close to this with a hierachical database.
We lose this with relational databases because the way the database organises data has no direct mapping to the way it might be set up in a standard programming language.
What this means is that every transaction to and from the database must go through a literally horrible re-mapping. IE. The language data structures do not correspond to the RDBMS data structures and visa versa.
You are confusing an RDBMS with a persistent storage mechanism. It's really not hard to just keep data persistent any more. You don't need a 3GL or anything fancy, just some hooks to record your modifications on permanent storage, and keep a small working set cached in memory. It's an easy, trivial, solved problem. And it was solved before relational databases were invented.
RDBMSs do a lot more. Here are just a few advantages:
* different applications can access the same data
* guarantee integrity via declarative constraints that can validate against all of the data at once, not just the single record in question
* different applications can have the same guarantees of integrity, and a bug in the first application can't break the guarantee for the second application
RDBMSs were invented for a reason. Many, many software bugs can be traced back to a bad data state -- some invariant that was broken and uncaught. Often, these bugs are not caught until long after the insert has taken place, and often cause a cascade of new bad data and you don't find out until many records are wrong. A lot of code is imperative, and re-stating the invariant declaratively (i.e. a database constraint) helps catch a lot of those bugs.
Trying to put these declarative constraints in the application is a bad idea. When should they be checked? And in which applications should they be checked (all of them, one would hope)? If you see a declarative constraint, are you sure it's correct, or might it have been added after inconsistent data was entered and before the constraint was actually run?
Databases solve this by making some promises. If you put a ".. CHECK (age > 0)" on an attribute, it will check all the records before applying it, and then all the records afterward will need to pass through that constraint. That's a lot better of a guarantee, and you know it's true for all applications. Someone else's bug or quick hack won't violate it, so your application can rely on that as the truth. Same with UNIQUE or FOREIGN KEY.
If you think about your reasoning for a moment, it's very narrowly focused on storing and retrieving single records. Presumably, anything needing to look at the data as a whole would need to read it fully into the application and process it from application code.
You don't take into account other readers of data who might require consistent reports or anything else that needs to look at more than one record. You also don't take into account the horrible mess you have when the application is wrong and stores bad data, or when you need to do data format changes. In the types of databases you describe, almost any change requires reorganizing the data physically. In an RDBMS, you can make many changes without physically changing the physical layout.
Slashdot Mirror
So you basically want incontrovertible proof that this passage hasn't been open in 400 years?
Nope, the article is what proclaimed that this is the first time in history for this kind of event. I just want some supporting data more than "a few explorers we sent didn't make it" to justify the article's claim. It is entirely unreasonable to make such a claim based on a few voyages. It may be true, the the article didn't say "may be".
Do you have some more convincing data than the article provided? If so, I'd like to see it.
The article in question said "in history" and then provided no useful information to back it up. That doesn't help your cause, even if it is true.
but that does not mean you discount all observations less than infinite.
I'm not discounting them. How many are there? A few expeditions? Is that really enough to suggest that the passage was closed for a long period of time without interruption? There isn't even one expedition per year, so that leaves lots of huge holes in the claim.
I am very willing to accept the data. I just don't think it's a reasonable logical step to go from:
"A few expeditions failed" to "the passage must have been closed since at least the first expedition".
but your reasoning is a tired, specious
You are the one using specious reasoning. A few expeditions failed, so it must have been closed the entire time (except, of course, in 1903)?
If they really want to help Python, build some online documentation that [isn't bad]
There are a few under-documented libraries that I've run into before, but largely I've been happy with the python docs.
I could swear you were talking about Ruby, because that's exactly the way I feel about Ruby (a language I love, but the docs are disorganized, decentralized, and generally poor).
What if it opens up on an annual basis? Will you then acknowledge that this is at least unprecedented in the last 400+ years?
Only if the historical data is sufficient to say that, over the last 400 years, there have not been 2 consecutive years that it's been open. I don't think a few [dozen] explorers proves that, either.
Actually, there is data going back thousands of years in the form of ice cores -- or there used to be. Of course, these haven't been done along the entire passage
If you have a fairly good sampling of carbon-dated ice cores from areas that are likely to be the first to melt, I'd accept that as good data. It would be quite convincing that the passage was closed if you said "there was a big sheet of 5000 year old ice blocking the passage, until this year".
A very large number of relatively rich people in CA does drive up the median.
The reason median is a useful statistic is because it represents an "average" (you might say "typical") player within the group. If your argument is that a "typical" Californian home purchaser paid $200k, then I think the median of ~$450k refutes that.
You seem to be measuring in kind of a strange way (not wrong, just not a number that most people deal with). What it seems to me that you mean is: if you throw a dart at a map of California, and buy an house on an acre there, how much will it cost? If that's the question you're asking, I'm willing to believe your numbers.
and several attempts have been made since then
Did you happen to notice that one of those attempts was successful in 1903?
My point is that when people see a headline about the first time "in history," they aren't thinking 30 years, they are thinking 3000 years. But 30 years is all we have any good data about at all. The fact that previous attempts failed does not mean that the passage did not exist previously, there are many plausible explanations, such as:
(1) they went at the wrong time of year
(2) they went the wrong year
(3) they couldn't find/navigate the route
We now have satellites, so we can see whether it exists or not, year-round. That's a much better tool than "we sent a few explorers, and they didn't make it, therefore the passage does not exist."
You accuse me of fear, uncertainty, and doubt. But it's hard to buy into this global warming hysteria (I believe some of the claims, it's just the hysteria that I don't buy) when publishers continue to sensationalize headlines. Then you come along and pretend that a few explorers going there on a few occasions proves something about the existence over a long period of time. It doesn't. There is simply no good data about that general area to support the claim that it was impassible for 400 years straight until 2007; and there's certainly no good data to support the claim that it was impassible for the thousands of years straight until 2007. I know the article didn't make that claim directly, but that's what someone reading the headline is lead to believe, so it is deceptive even if it might not be technically dishonest.
If its never been passable before why was it called a passage?
It seems as though the article defines "history" to be the last 30 years, since we've had satellites monitoring it. Doesn't seem nearly as amazing to me. I'm sure the people who published the article knew that they were being deceptive at the time (even if they are technically correct), but real headlines don't cause the hysteria they are seeking.
The ridiculously rich with extravagant homes may push the average price up, but that doesn't change the facts that low priced homes are out there.
The median is not the mean. "Rediculously rich" people don't drive up the median anything at all.
before [OpenBSD] destroys any ounce of credibility it still has.
The developers of, among many other achievements, OpenSSH, have more than an ounce of credibility. Any attempt to marginalize a group that's produced such a vital, omnipresent contribution is an attempt to rewrite history.
We should remember that security is hard and that to produce secure software requires not just the will but also rare ability.
Your other criticisms may be valid, but we should remember who we're talking about here. Security experts are among the most difficult developers to replace. There's a reason that we're talking about OpenBSD on slashdot right now: the viability of the project could have an impact on many people.
http://www.realestateabc.com/graphs/calmedian.htm
I don't see how you can say that an acre or two and a big house for $200k is representative of California with median home prices what they are. I certainly don't think it's representative of the people in California.
the point was that those places make up a tiny fraction of California
But they make up a large fraction of the population, and a large fraction of the total dwellings.
However, I am well within a 1 hour drive of much of Los Angeles, and just recently sold my previous house on a 1 acre lot for $150,000
So, you can commute to/from downtown LA during rush hour in less than 60 minutes, and you live on one acre, and it's only worth $150k?
By "within an hour of" I didn't mean 60 miles from the outskirts of the greater metropolitan area.
Its because making it big is 99% luck and less than 1% hard work.
Of course those people had some great opportunities that are very rare -- even among the rich.
The reason these guys are successful is because you could give those same exact set of opportunities to a million people, and none of them would make anything out of those opportunities. It might be too risky for their tastes, or they might not be comfortable working 80 hour weeks when it really counts. Or, they might not realize how lucky they are, and wait for the next once-in-a-lifetime opportunity to come along.
Anywhere outside of the few largest cities (eg. the greater Los Angeles and San Francisco area), and 200K will easily buy you a big house and an acre or perhaps two
I suggest you look around to see what $200k will buy you in California. If you are within two hours of either of those places, get prepared to pay a lot more than that for "a big house and an acre or perhaps two". Same if you are anywhere near the coast.
You should be thinking more along the lines of $300k for a tract home, unless you go to some fairly remote areas.
It's quite likely that your ancestors didn't enter this nation legally either.
In the US, you aren't punished for someone else's unlawful acts.
Marrying for the sake of citizenship
That's not a "trick", that's following the law.
American laws have always been xenophobic to varying degrees
Laws don't fear, people do.
Our laws have always been somewhat xenophobic for a nation that prides itself as a melting pot
How is giving an advantage to one group, Mexicans, at the expense of other groups, like Asians, helping us become a better melting pot? Being opposed to illegal immigration does not mean I'm opposed to immigration. I oppose the current policies, which shift the balance heavily in the favor of illegal Mexican immigrants at the expense of all others. We should, as a nation, be able to decide who gets in and who doesn't, and to conduct the immigration process in an orderly way.
Illegal immigration is an administrative violation
Should we have immigration laws, or should we have no immigration laws at all? This question is not rhetorical, but an important question that few illegal immigration advocates will answer.
I believe that they are important. Because of that, I believe they should be enforced. I don't care what level of violation it is, if it's important, the laws on the books should be enforced using the limited powers of the government. That is called "The Rule of Law," and it is one of the most important aspects of Western society, in my opinion.
Not really, criminals need light too.
If you make lights illegal, only criminals will have (flash)lights.
I can sympathize that women are outraged by the high number of men that get off scott-free with these type of charges
What makes you think that any of the men who get off scott-free are guilty of anything?
My point had nothing to do with adherence to the SQL standard (although in my opinion, MySQL's default behavior is further away than other databases). My point was that changing the storage engine (the physical storage mechanism) changes the semantic behavior of commands. MyISAM behaves differently than InnoDB, and you might need to change your application code if you want to change storage engines.
Sun is not historically a friend of Open Source
What about OpenOffice and OpenSolaris? Are you suggesting that they did something so evil that it counteracts these important projects?
It doesn't matter at all why they support free software.
I'm about to do some really, really big archiving projects, ... Break it, Break it, Break it, get it right.
;)
:)
I don't envy that task
With a topic like databases, there are a million people pulling in different directions and they have different perspectives -- and different business incentives. There are two things that always work to get to the bottom of any discussion super-saturated with opinion:
(1) Try to understand a lot of perspectives.
(2) Look for people who have a very good grasp of logic, a lot of knowledge, and a good reputation, and learn some fundamentals from them. When you do this, you can cut through 90% of the crap in no time.
I personally recommend reading anything by C.J. Date. He's a leader in relational theory, he's very logical, and has a writing style that works for me. It took me a while to appreciate a lot of his ideas, however. It might not help on your current project, except perhaps giving some hints on best practices (assuming that you buy into his arguments). Note: I own 4 of his books, so I'm probably violating rule #1, so whatever you do, don't consider me a member of group #2
It could become a new storage engine for MySql,
Every current storage MySQL engine choice changes the semantics and forces you to give up features.
I wonder what basic features you will have to sacrifice in order to use this hypothetical new storage engine.
surrogate keys you're talking about -- which are technically a design flaw (or perhaps a "design smell" to crib an XP term), but they're kind of unavoidable for efficiency (I sure as hell don't want to sling around whole arrays of street/city/state/post in my CRM app)
...).
If by "efficiency" you mean performance, the surrogate keys are a physical implementation detail and should be hidden from the application, in which case you don't have any surrogate keys at all.
If by "efficiency" you mean that you prefer to deal with data by assigning new logical names (e.g. an employee ID) that the application/user actually care about, then that's not a surrogate key either, but a real key. Even though my driver's license number is generated, I still know what it is, and still may need to identify myself by that number in some situations. So it's not a surrogate key.
A surrogate key is when you start muddying the distinction between the logical and physical layers. A surrogate key is something that appears in the logical layer but has absolutely no meaning to anything outside the database. Why present something at the logical level that is meaningless at the logical level? It's essentially like the database spitting out physical addresses to the application code ("INSERT successful, record stored on block number 1234 on volume 4576, and it was also at memory address 0x12345678 for a while
Products like MySQL seem to get along just fine supporting multiple options for storage engine.
Except that in MySQL, changing the storage engine means that it will not "still be SQL" it will be a different variant of SQL, with different features available and different semantics. The storage engines aren't independent of the logical level. That is one of the biggest failings of MySQL.
You are confusing an RDBMS with a persistent storage mechanism. It's really not hard to just keep data persistent any more. You don't need a 3GL or anything fancy, just some hooks to record your modifications on permanent storage, and keep a small working set cached in memory. It's an easy, trivial, solved problem. And it was solved before relational databases were invented.
RDBMSs do a lot more. Here are just a few advantages:
* different applications can access the same data
* guarantee integrity via declarative constraints that can validate against all of the data at once, not just the single record in question
* different applications can have the same guarantees of integrity, and a bug in the first application can't break the guarantee for the second application
RDBMSs were invented for a reason. Many, many software bugs can be traced back to a bad data state -- some invariant that was broken and uncaught. Often, these bugs are not caught until long after the insert has taken place, and often cause a cascade of new bad data and you don't find out until many records are wrong. A lot of code is imperative, and re-stating the invariant declaratively (i.e. a database constraint) helps catch a lot of those bugs.
Trying to put these declarative constraints in the application is a bad idea. When should they be checked? And in which applications should they be checked (all of them, one would hope)? If you see a declarative constraint, are you sure it's correct, or might it have been added after inconsistent data was entered and before the constraint was actually run?
Databases solve this by making some promises. If you put a ".. CHECK (age > 0)" on an attribute, it will check all the records before applying it, and then all the records afterward will need to pass through that constraint. That's a lot better of a guarantee, and you know it's true for all applications. Someone else's bug or quick hack won't violate it, so your application can rely on that as the truth. Same with UNIQUE or FOREIGN KEY.
If you think about your reasoning for a moment, it's very narrowly focused on storing and retrieving single records. Presumably, anything needing to look at the data as a whole would need to read it fully into the application and process it from application code.
You don't take into account other readers of data who might require consistent reports or anything else that needs to look at more than one record. You also don't take into account the horrible mess you have when the application is wrong and stores bad data, or when you need to do data format changes. In the types of databases you describe, almost any change requires reorganizing the data physically. In an RDBMS, you can make many changes without physically changing the physical layout.