I was not aware that mathematics changed depending on what the regulations were. The normal forms are defined by cold hard mathematics.
One of the main points of third normal form is that there are no transitive functional dependencies. While it is not mathematically impossible that you could have a 300-row table which has no transitive funcitonal dependencies, I would find it highly unlikely.
Suppose, for example, that you are required to keep the supplier's current address and tax id for a part (and you only order from one supplier). First normal form would allow you to put all these in the same table. Third normal form would not because you have a transitive functional dependency. Part_id -> supplier_tax_id -> supplier_current_address. Hence you would have to break off the supplier information into a new table.
Hmmm.... Interesting experiments. However I am not really clear on them. What I would want to know is how we definitively know that the electron is entangled with its position and whether this has to do with the other electron in the entangled pair perhaps being absorbed by the barrier.
What I would like to know is if there is any definitive proof that if we take two entangled electrons and put them through these devices, absorbing neither one, that they are not entangled at the end.
If we put entangled photon pairs down different fiber lines, and include a birefringent component to split the beam into polarized components... Each photon ought to essentially split itself. We wouldn't know which path a given photon took until we measured it, but we would know what the properties were supposed to be based on the waveform collapse.
In this case, the observation would be the exact same as it the photon actually had a discrete property which caused it to choose one path as it hit the crystal.
Note, however, that Heisenberg never suggested that the photon would be both at once. He simply said one could not *know* what state it would have until observation without knowing the exact "state of everything else in the universe" ("Physics and Philosophy"). Most physicists also don't suggest that an electron takes up the entire space of an electron cloud, just that such is a "useful way to think about it."
In short in this case, we cannot know whether the photon *really* took both paths and later collapsed that into a choice, or chose one in when it reached the crystal. Postulating about unknowables seems to be a little like Intelligent Design. On the other hand, you may just be confusing the map with the territory:-)
IANAP, but there were plenty of them in my family.
CUrrently we lack an ability to select an electron based on spin without entangling it with another electron and thus breaking other entanglements. However, is this an issue with our technology or with the science behind it?
Suppose we look at photons with entangled polarities instead. At least in theory we ought to be able to use birefringence to select photons based on known polarity properties. Thus we ought to be able to know what the polarity was supposed to be before we rotate it. Thus the noncommunication theorem might be a mere technological limitaton as opposed to a fundamental principle. We will have to see.
First, the reason why many or most languages' floating point types is that they internally represent their data as binary numbers. The rounoff error occurs when you convert a decimal floating point number into a binary floating point number. No base system is entirely free from these. For example, one woul dnot be able to convert 0.1 base 3 to base 10 without truncation.
Not all languages have this problem, however because it is not the only way to procede. Basically in any base number system, you have an ordered list of digits each of which is related to its neighbors by being a multiplier to the base raised to a power related to its position. So if I write: 1034.23, what I really have is 1x10^3 + 0*10^2 + 3*10^1 + 4*10^0 + 2*10^-1 + 3*10^-2. Addition is then straight-forward, and multiplaction is based on its distributive property. Since any integer digit can be stored in binary, one can build arbitrary base systems (and operate with them) even though the data is actually stored in binary. Decima-safe floating point systems tend to use a power of 10 as its base. For example, PostgreSQL uses base 1000 for its numeric data type (larger bases are more efficient when it comes to binary representation because you have fewer bits lost).
I know that C and Javascript use floating point types which are not decimal-safe. Perl, Python, and Ruby seem to have decimal safety built-in.
AI would also note that arbitrary precision libraries can give you roundoff errors too but for a different reason. These libraries are generally designed to work primarily with scientific measurements where you have to take into account the accuracy and precision of those measurements. Operations like rounding numbers can have unexpected effects down the road if you are not familiar with these.
For example, suppose we take:
$float = Math::BigFloat::new(10.011); $float->bfround(-2); # produces 10.01 $float->bdiv(10); # produces 1.00 due to the fact that we now have a set precision (-2) on the number!
$float2 = Math::BigFloat::new(10.001); $float2->bsub($float ); # produces 9.00 because of the fact that float has a precision of -2!
Ok, attribute-value modelling has its uses. We use it in LedgerSMB in exactly 2 places (argument lists for functions called on menu element activation and system settings). However it is *horrible* when you are trying to impose a natural structure on data.
In many cases your observation would be true that once you are getting up to 100 fields in a row that this is really pushing it.
My experience is that db tables of more than about 10 columns tend to be indications that something may be wrong. The only tables I have ever seen with more than 50 columns have all been badly designed (thus far). While this is not a mathematical rule, it does seem to match my experience.
However with geological data this is not always the case. Consider a borehole in a mining setting. The hole lives at a certain location and has directional information. The borehole is identified by an ID.
Ok, so far we have latitude, longitude, and id.
It was drilled by such adn such a company at such and such a time and hence it still makes sense to carry all this data in a row identified by the borehole ID. If one breaks this data into multiple rows - then a merge may need to take place and this can be costly compared to the much easier job of just ignoring a few fields which are not needed.
Ok, we add a timestamp, and a company identifier (which joins to another company table).
So far we have:
create table borehole (
id int not null unique,
latitude numeric not null,
longitude numeric not null,
company_id int not null references company (id),
time_drilled timestamp not null,
PRIMARY KEY (latitude, longitude, time_drilled) );
Add to this it issue that if you have split the rows up then some of the data may be missing and some may be duplicate because the data structure allows it.
THe above seems very straight-forward. Note the NOT NULL constraints, and the foreign key constraints.
Note that if oyu put all company information in the same row you are adding duplicate information, and this can cause data management problems.
Now if you had two contractors drilling the same borehole then I would agree and say split the contractor data into one table and the technical data into another. In fact that was done even though there is no possiblity of having two or more contractors on a borehole. If something funny happens one can always assign a new borehole ID anyway.
No, I think you have that backwards. If you can have two holes drilled by the same contractor, you want to split the contractor data into another table. If you have two contractors drilling the same hole, you will need to create a pivot table for the many->many mapping.
Look at the technical data.
Isotopic signatures may be taken. There are over 100 isotopes alone.
Each isotope signature record belongs in a different row.
Various mineral assays can be conducted. The number of fields here is also large.
Same as above.
What happens if you want to start looking for another isotope or run a different mineral assay? Do you want to alter the schema of the table? Or rather add a field into an isotope or assay table that tells people about the test so you can store the results in another one.
In short it is quite easy to end up with more than 100 fields.
You still need to look up normalization.
Ok, take the above table for borehole and add the following tables:
create table isotope (
id int not null unique,
element_number int not null,
element_mass int not null,
PRIMARY KEY (element_number, element_mass) );
create table assay (
id int not null unique,
name text not null,
description not null,
PRIMARY KEY (name) );
CREATE TABLE isotope_result (
borehole_id int not null references borehole(id),
isotope_id int not null refere
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.
I think there is a key distinction here. Application object store vs data management. Hierarchical db's are far better at storing object information, but *far* worse at real data managment.
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.
In LedgerSMB, we solved this by putting a functional interface in the db. Then we dynamically map the objects and their properties into functions and arguments. Works great:-)
As an example - in postgreSQL the last I looked at writing a simple row into a table where there were something like 100 columns in the row...
You are either trolling or you need to fire the DB architect who designed that. THere is *no way* that a 100-column table is good DB design. (Ok, mathematically, there is nothing that precludes it being good db design, but I can't even imagine a scenario where this would be OK).
In the 3rd generation programming languages this was just a simple structure with 100 entries.
Oh, you were the one who designed the 100-column table. Sorry..... Please go out and get some books on db design. You will thank me:-)
The data transfer from that structure generated a function call with more than 1000 parameters. This was to be mapped and re-mapped with each call to transfer data, this is even though the structure itself is static and determined at compile time.
IMO, your problem honestly is in the fact that you are using a monkey wrench as a ball peen hammer. It may sorta work but you are using the wrong tool for the job. If you want a simple object store use BDB or something like it. If you want a real data management solution, build your db *first.* If that is not your goal, use something other than an RDBMS.
Next: There were about 10 parameters per field (column).
1: Column name 2: Column name length 3: data type 4: data length 5: character representation... etc
finally 10: Address where the data lives.
The thing is such a table could be set up very easily and populated with a simple loop that rolls in the required values via say a mapping function with about 10 arguments. This could be done ONCE at run time to prepare for the transfer of data and then the same table could be referenced for each call and simply an address could be sent with the transfer.
Noooo.. It was dynamic and the data was encoded as parameters on the stack. This means the stack must be build and torn down and rebuilt for each call.
How is this an issue with RDBMS's?
Next - the implementation was so bad that the program would run in test mode with only a few parameter but it failed when the whole row was to be transfered.
Again, this is not a PostgreSQL problem;-)
I gave up on that interface.
From your description, that sounds like a wise choice.
While there is much good to say about RDBMS's in general. The issue I ran into was the interface from 3rd generation languages took a HUGE step backward. IMHO we should have a high level language statement called DBRead() and DBWrite(). In C this should generally correspond to fread() and fwrite(). If this is too complex then DBWriteStruct() could be implemented with suitable mapping helper function.
Again, this is an issue with the frameworks you are using. Personally, I tend to do the
You seem to think that RDBMS's are obsolete. What do you think they should be replaced with? Even Stonebreaker isn't suggesting that set-theory-based math isn't the right way to go-- he is talking aobug physical storage choices (which work better in some cases), not the theoretical math basis for the information management.
I don't know. I think the reason we have issues with keys to this day is that data engineers don't tend to understand the math involved. Abstract id's while OK should probably not be used as primary keys (use a natural primary key where possible).
As for object abstraction... object representation may be functionally dependent on referential representation, the same cannot be said of the converse.:-) The best approach I have found is to put as much of the mapping logic into the db as possible using stored procedures and then you dont have to worry about it in your application.
If you are doing killer aggregates (tell me the sum of the sales in every month for the last 25 years), you are going to be limited by possibly 2 things: CPU cycles and disk I/O throughput.
There are several ways of addressing these issues. Basically this means either optimizing or parallelizing. Column-oriented stores are likely to help optimize the disk i/o throughput so you can just thow more processor effort at the problem.
You can also do what Teradata and BizgressMPP do which is basically break the database into lots of little db's running on different servers and distribute the disk and processor time that way. Iirc Oracle and DB2 also offer this sort of option. Depending on how this is set up, it may be possible to use in an OLTP environment as well.
On the other hand, suppose you are doing a lot of updates in a high transaction load environment. Which would you rather do? Update each column value (and skip around the disk doing this) or update the entire row on one disk block?
Column-oriented databases are helpful for some things. They are not the only solution to the problem out there. And they are still relational. Hint: They are still based on Edgar Codd's relational mathematics.
I don't doubt that there are legal obstacles to fully open source drivers. However, I was mostly trying to use nVidia as an example of concrete, practical problems with closed source drivers.
With nVidia, I think that people like to blame them too much, but they do make a good example of the problems of closed source drivers on something like Linux.
On the other hand, maybe it is time we start petitioning SGI to allow an open soure driver for the nVidia cards:-)
If you read my journal, you will see that I am hardly the Stalin^H^Hlman type. I tend to think that we should be looking at pragmatism as a foundation of idealism not the other way around.
THe basic issue, however, is that nVidia drivers generally (at least in my experience) tend to require more effort to get installed than they should if you start to move outside of the most common process ro configurations. For example, on one of my Fedora boxes, I can get a kernel that works well with my processor or a precompiled 3d video card driver. I cannot get both. This gets worse as you move away from IA32/64 architectures.
So if you want every Linux user to be able to *easily* use the driver, it *needs* to be open source.
I thought MS bought Hotmail in 1997, but kept running it on FreeBSD until sometime in 2000 simply because nobody could figure out how to migrate that sort of environment over.
I don't think it will. And wasn't Hitler Christian? According to some of his correspondences with Himmler, Hitler suggested that Science was the religion of the future and that the proper reaction to Catholicism and Protestantism was to let them fade away. While he may have had a Christian upbringing I don't think it is possible to call him a Christian.
The difference is that a scientist is looking for a reason why, and looks out in the world around him. Where do you turn to if you want to approach this from a religious point of view? No. Scientists theorize about potential mechanisms. In essence we take guesses about "how" rather than "why."
You turn to scripture and maybe intuition. Scripture is pure dogma, and intuition is a guess, one that should give you direction on where to look for your evidence. My tradition does not have scripture as do the Monotheists. We have mythic tales, told with the intent to inspire and stretch one's mind. They are the initial steps on the quest for meaning, not dogmatic doctrines. Secondarily I turn to academic studies such as Dumezil's comparitive method, and the work of historical linguists and philologers.
You know what I see when I look beyond logic?
I see beauty.
I see color and sound, anger, love, and all kinds of things for which there is no logical cause or process.
I do not see a mythical sky-god. Funny, Odin looks like a sky god. But what is he really? The Indo-Europeans were not nature-worshipers-- their religion was centered around human and social concepts.
The etymology of the name suggests Odin is a mythical mind-god primarily (Odin, from Odhr + inn, meaning "master of Odhr." Odhr means song, frenzy, inspiration, or madness. Calvert Watkins (linguistics professor and author of "How to Kill a Dragon") translates "Odin" as "the incarnation of shamanic wisdom." Note, however, that this is the wisdom of a madman (compare with the Irish story of "The Frenzy of Suibhne").
The Indo-European traditions were very human-centered traditions. We were not here to serve gods, but rather there was a symbiosis between the divine and the human in this view. The religions appear to have evolved organically as an almost philosophical approach to understanding abstract social concepts. If you doubt this, note that today, there are Roman goddesses which stand in our government buildings which represent some those concepts (Libertas and Justitia), and their names, translated into Modern English are in our Pledge of Allegiance.
Furthermore Indo-European mythic chronology is very modernist. There is an idea in Indo-European mythic structures that humans are supposed to try to make the world a better place. This can be contrasted with the Abrahamic (perhaps originally Zoroastrian) structure which supposes that the world has fallen from grace and will be redeemed in its destruction.
My suspicion is that the Indo-Europeans probably evolved from an agrarian people who worshiped a sky-father ( -> Greek Diu-Piter) and an earth goddess. However two things occurred together which changed all this:
1) They acquired bronze technology 2) They domesticated the horse or acquired domesticated horses.
From these came a third: They invented the spoked wheel which quickly revolutionized their society. They probably suddenly became wealthy and developed a class of philosopher-priests who began to approach these things and guide (through a warrior who was deemed most worthy) the adminitration of justice. There is more to the story than this, but it is what my research has lead me to conclude.
My reading of Plato suggests that he largely took ideas from mythology and framed them in philosophy.
Science is an ontological process. Neoplatonic philosophy had a different ontological process. Quakerism has yet another ontological process. None of these process can work without a guiding philosophy beyond the process itself. In short, since theory is never functionally dependant on data (even when factoring in process), two people can always look at the same data and see different reasons why.
Hence science *never* tells us why something works. We can only create theories which are falsifiable.
And ancient philosophies have a way of coming back to haunt us. "Fire is the prima materia" (paraphrased from Heraclitus) is simply a cruder version of "E = mc^2" (or at least so says Heisenberg in "Physics and Philosophy").
The people who suggest (like Hitler but unlike Heisenberg, Einstein, and others) that science will outmode religion have yet to come up with a convincing explenation why so many scientists are deeply religious. More likely religion is a fundamental part of the human condition, not a mere construct of faith but a way of describing and explaining certain experiences beyond what normal language is able to convey. I do not believe that there is "one" true religion as the Christians believe, or even one perfect religion as the Muslims do. Instead, I believe that every religion is a combination of that spark of human experience (perhaps the peak experiences A. Maslow wrote about are a subset), fleshed out by culture and tradition until it forms a language (and political structure, and the like). As I am more interested in the language.
My religion is that of the scholar in search of the distant unifying principle behind the earliest Indian religious writing, and related traditions from Europe (Celtic, Greek, Norse, Old English). My practices are Norse pagan for the most part.
When we devote ourselves to logic, we ignore the fact that our brains are not wired to be strictly logical. Instead our brains are generally image-oriented and one cannot conceive of a negative without imagining its opposite, so one must understand that words like "no" or "not" tie us to the images that we seek to distance ourselves from. True mastery over ourselves requires mastery over logic, but also an ability to move beyond it to build a more powerful image of the universe within our minds.
Nor can it be proven. Until such time as the big guy walks into my living room and shakes my hand, I'll be skeptical, thank you very much.
Oh, and news flash:....
#2 not everyone agrees with you (matter of fact, some people regard mainstream religion as highly offensive and insulting), #3 just because someone disagrees with you, doesn't mean they're 'wrong'. BUt if everyone agrees with me, evidently anyone who might disagree with me would be wrong;-)
(Please reread the summary and TFA before replying to this post)
I noticed this a few years ago in my religious and mystical studies. I noticed that we don't have a capacity to think in negative images, and hence when one states a negative (i.e. "Saddam didn't plot 9/11") the image which one visualizes is that of the opposite of the stated goal. It confirms that our brains are not logical in operation but rather use some other form of processing and storage.
One of the interesting challenges is then that one must counter this sort of thing with active imagery. For example, "Al Qaeda targetted Saddam as well as the US."
Interestingly, I suspect that, when you look at traditional Indo-European liturgical works, many structures in the poems seem to indicate an awareness of this concept. For example, a most of the uses of negative elements seem to occur as supplimental to the positive images, reinforcing those positive images (i.e formulas like "bound an not bound")
1) Restricting freedom seems to be OK in the advancement of The Cause. For example, allowing invariant sections via the FDL in order to force people to republish the GNU Manifesto.
The GPL is about restricting the freedom of developers so as to provide more freedom for users. The BSD license is the other way around. But there are a lot more users than developers.
I think you are missing my point. The GPL2 I thought was a *good* balance between enforced reciprocity and freedom. While BSDL communities can provide some incentives for contributing back, the GPL2 was a *safer* bet for businesses doing an initial release.
However, my point was about the GFDL. The FDL allows authors to restrict freedom of downstream recipients to a level that even Debian feels is beyond the point of Free Software. The reason for this change was a desire for *forced advocacy* in versions of the Emacs manual. This sort of forced advocacy was exactly why Debian does *not* consider FDL documentation to be automatically Free (any invariant sections make the work unFree).
Do some research on what RMS had to say about the reason for the invariant sections clause and then come back to me;-)
The GPL3 has other issues....
2) Wielding a club without first taking a look to see whether it is necessary or beneficial: Tivoization clauses, for example. I think this actually a bad thing in terms of giving people more incentive to rethink effective DRM schemes, and the like. Furthermore, I believe that competition will always promote freedom in the end.
Unrestrained competition does not generally promote freedom; it generally promotes feudalism. No, I'm not joking. Half the point of government intervention in markets is to deal with market failures: situations where an unrestricted market does NOT generate an optimal result. Health care, transportation, and utilities are all examples where unregulated systems invariably lead to abusive oligarchies. (This is not to say that regulation is perfect, obviously, but we could spend lifetimes arguing economics.;))
So you really want to spend your money trying to lock customers out of modifying your box? Someone else can spend less, provide the same features, and not have to do this. And since they have access to the code, it is sort of stupid to even try.
However that's not especially relevant to the GPL; nobody is forcing the GPL on anyone, they're merely providing it as the license they encourage people to use.
Nor does the GPL really prevent Tivoization.
Suppose I create a Tivoized box with GPL3 software. It works in the following way: 1) The loadable boot image is digitally signed. No digital signature, we don't load. The boot image contains the master OS w/hypervisor, VM-based portions which provide control over large portions of the hardware, etc. This image can only be upgraded as a unit.
2) I also provide the GPL sourcecode and instructions for getting it to run on the bare hardware. It also comes with an encryption key which is different from the one I sign my code with. That way, we always know whether the code is really unaltered ro not for support cases.
3) All access to services, automated or otherwise, require a handshake to determine that the OS is unaltered.
Now, you can compile the object code, get it to run without interference, etc. However, because you are lacking the hypervisor and related components, you can't really use the box for its intended purposes. HDTV is no longer accessible. Maybe even the coax input doesn't work because *that* is managed in a virtual environment.
We could even supply (and even require) a hypervisor that doesn't allow for direct access to these components, forcing the user to reverse engineer the whole thing in a different OS vm. Since that other component onl
Slashdot Mirror
I was not aware that mathematics changed depending on what the regulations were. The normal forms are defined by cold hard mathematics.
One of the main points of third normal form is that there are no transitive functional dependencies. While it is not mathematically impossible that you could have a 300-row table which has no transitive funcitonal dependencies, I would find it highly unlikely.
Suppose, for example, that you are required to keep the supplier's current address and tax id for a part (and you only order from one supplier). First normal form would allow you to put all these in the same table. Third normal form would not because you have a transitive functional dependency. Part_id -> supplier_tax_id -> supplier_current_address. Hence you would have to break off the supplier information into a new table.
Hmmm.... Interesting experiments. However I am not really clear on them. What I would want to know is how we definitively know that the electron is entangled with its position and whether this has to do with the other electron in the entangled pair perhaps being absorbed by the barrier.
What I would like to know is if there is any definitive proof that if we take two entangled electrons and put them through these devices, absorbing neither one, that they are not entangled at the end.
If we put entangled photon pairs down different fiber lines, and include a birefringent component to split the beam into polarized components... Each photon ought to essentially split itself. We wouldn't know which path a given photon took until we measured it, but we would know what the properties were supposed to be based on the waveform collapse.
:-)
In this case, the observation would be the exact same as it the photon actually had a discrete property which caused it to choose one path as it hit the crystal.
Note, however, that Heisenberg never suggested that the photon would be both at once. He simply said one could not *know* what state it would have until observation without knowing the exact "state of everything else in the universe" ("Physics and Philosophy"). Most physicists also don't suggest that an electron takes up the entire space of an electron cloud, just that such is a "useful way to think about it."
In short in this case, we cannot know whether the photon *really* took both paths and later collapsed that into a choice, or chose one in when it reached the crystal. Postulating about unknowables seems to be a little like Intelligent Design. On the other hand, you may just be confusing the map with the territory
IANAP, but there were plenty of them in my family.
CUrrently we lack an ability to select an electron based on spin without entangling it with another electron and thus breaking other entanglements. However, is this an issue with our technology or with the science behind it?
Suppose we look at photons with entangled polarities instead. At least in theory we ought to be able to use birefringence to select photons based on known polarity properties. Thus we ought to be able to know what the polarity was supposed to be before we rotate it. Thus the noncommunication theorem might be a mere technological limitaton as opposed to a fundamental principle. We will have to see.
Is that like putting bread dough in the refrigerator in order to try to reverse the rising process?
Not all languages have this problem, however because it is not the only way to procede. Basically in any base number system, you have an ordered list of digits each of which is related to its neighbors by being a multiplier to the base raised to a power related to its position. So if I write: 1034.23, what I really have is 1x10^3 + 0*10^2 + 3*10^1 + 4*10^0 + 2*10^-1 + 3*10^-2. Addition is then straight-forward, and multiplaction is based on its distributive property. Since any integer digit can be stored in binary, one can build arbitrary base systems (and operate with them) even though the data is actually stored in binary. Decima-safe floating point systems tend to use a power of 10 as its base. For example, PostgreSQL uses base 1000 for its numeric data type (larger bases are more efficient when it comes to binary representation because you have fewer bits lost).
I know that C and Javascript use floating point types which are not decimal-safe. Perl, Python, and Ruby seem to have decimal safety built-in.
AI would also note that arbitrary precision libraries can give you roundoff errors too but for a different reason. These libraries are generally designed to work primarily with scientific measurements where you have to take into account the accuracy and precision of those measurements. Operations like rounding numbers can have unexpected effects down the road if you are not familiar with these.
For example, suppose we take: Hope this makes more sense.
Ok, attribute-value modelling has its uses. We use it in LedgerSMB in exactly 2 places (argument lists for functions called on menu element activation and system settings). However it is *horrible* when you are trying to impose a natural structure on data.
With regard to say 100 fields in a row.
In many cases your observation would be true that once you are getting up to 100 fields in a row that this is really pushing it.
My experience is that db tables of more than about 10 columns tend to be indications that something may be wrong. The only tables I have ever seen with more than 50 columns have all been badly designed (thus far). While this is not a mathematical rule, it does seem to match my experience.
However with geological data this is not always the case. Consider a borehole in a mining setting. The hole lives at a certain location and has directional information. The borehole is identified by an ID.
Ok, so far we have latitude, longitude, and id.
It was drilled by such adn such a company at such and such a time and hence it still makes sense to carry all this data in a row identified by the borehole ID. If one breaks this data into multiple rows - then a merge may need to take place and this can be costly compared to the much easier job of just ignoring a few fields which are not needed.
Ok, we add a timestamp, and a company identifier (which joins to another company table).
So far we have:
Add to this it issue that if you have split the rows up then some of the data may be missing and some may be duplicate because the data structure allows it.
THe above seems very straight-forward. Note the NOT NULL constraints, and the foreign key constraints.
Note that if oyu put all company information in the same row you are adding duplicate information, and this can cause data management problems.
Now if you had two contractors drilling the same borehole then I would agree and say split the contractor data into one table and the technical data into another. In fact that was done even though there is no possiblity of having two or more contractors on a borehole. If something funny happens one can always assign a new borehole ID anyway.
No, I think you have that backwards. If you can have two holes drilled by the same contractor, you want to split the contractor data into another table. If you have two contractors drilling the same hole, you will need to create a pivot table for the many->many mapping.
Look at the technical data.
Isotopic signatures may be taken. There are over 100 isotopes alone.
Each isotope signature record belongs in a different row.
Various mineral assays can be conducted. The number of fields here is also large.
Same as above.
What happens if you want to start looking for another isotope or run a different mineral assay? Do you want to alter the schema of the table? Or rather add a field into an isotope or assay table that tells people about the test so you can store the results in another one.
In short it is quite easy to end up with more than 100 fields.
You still need to look up normalization.
Ok, take the above table for borehole and add the following tables:
disk seek time is a real killer.
;-)
Instead of writing all the data in one operation, you get to seek, write, seek, write, seek, write, seek, write, etc.
Moving parts are slow
On the contrary.
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.
I think there is a key distinction here. Application object store vs data management. Hierarchical db's are far better at storing object information, but *far* worse at real data managment.
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.
In LedgerSMB, we solved this by putting a functional interface in the db. Then we dynamically map the objects and their properties into functions and arguments. Works great :-)
As an example - in postgreSQL the last I looked at writing a simple row into a table where there were something like 100 columns in the row...
You are either trolling or you need to fire the DB architect who designed that. THere is *no way* that a 100-column table is good DB design. (Ok, mathematically, there is nothing that precludes it being good db design, but I can't even imagine a scenario where this would be OK).
In the 3rd generation programming languages this was just a simple structure with 100 entries.
Oh, you were the one who designed the 100-column table. Sorry..... Please go out and get some books on db design. You will thank me :-)
The data transfer from that structure generated a function call with more than 1000 parameters. This was to be mapped and re-mapped with each call to transfer data, this is even though the structure itself is static and determined at compile time.
IMO, your problem honestly is in the fact that you are using a monkey wrench as a ball peen hammer. It may sorta work but you are using the wrong tool for the job. If you want a simple object store use BDB or something like it. If you want a real data management solution, build your db *first.* If that is not your goal, use something other than an RDBMS.
Next: There were about 10 parameters per field (column).
... etc
1: Column name
2: Column name length
3: data type
4: data length
5: character representation
finally 10: Address where the data lives.
The thing is such a table could be set up very easily and populated with a simple loop that rolls in the required values via say a mapping function with about 10 arguments. This could be done ONCE at run time to prepare for the transfer of data and then the same table could be referenced for each call and simply an address could be sent with the transfer.
Noooo.. It was dynamic and the data was encoded as parameters on the stack. This means the stack must be build and torn down and rebuilt for each call.
How is this an issue with RDBMS's?
Next - the implementation was so bad that the program would run in test mode with only a few parameter but it failed when the whole row was to be transfered.
Again, this is not a PostgreSQL problem ;-)
I gave up on that interface.
From your description, that sounds like a wise choice.
While there is much good to say about RDBMS's in general. The issue I ran into was the interface from 3rd generation languages took a HUGE step backward. IMHO we should have a high level language statement called DBRead() and DBWrite(). In C this should generally correspond to fread() and fwrite(). If this is too complex then DBWriteStruct() could be implemented with suitable mapping helper function.
Again, this is an issue with the frameworks you are using. Personally, I tend to do the
You seem to think that RDBMS's are obsolete. What do you think they should be replaced with? Even Stonebreaker isn't suggesting that set-theory-based math isn't the right way to go-- he is talking aobug physical storage choices (which work better in some cases), not the theoretical math basis for the information management.
I don't know. I think the reason we have issues with keys to this day is that data engineers don't tend to understand the math involved. Abstract id's while OK should probably not be used as primary keys (use a natural primary key where possible).
:-) The best approach I have found is to put as much of the mapping logic into the db as possible using stored procedures and then you dont have to worry about it in your application.
As for object abstraction... object representation may be functionally dependent on referential representation, the same cannot be said of the converse.
Ok, think about it this way:
If you are doing killer aggregates (tell me the sum of the sales in every month for the last 25 years), you are going to be limited by possibly 2 things: CPU cycles and disk I/O throughput.
There are several ways of addressing these issues. Basically this means either optimizing or parallelizing. Column-oriented stores are likely to help optimize the disk i/o throughput so you can just thow more processor effort at the problem.
You can also do what Teradata and BizgressMPP do which is basically break the database into lots of little db's running on different servers and distribute the disk and processor time that way. Iirc Oracle and DB2 also offer this sort of option. Depending on how this is set up, it may be possible to use in an OLTP environment as well.
On the other hand, suppose you are doing a lot of updates in a high transaction load environment. Which would you rather do? Update each column value (and skip around the disk doing this) or update the entire row on one disk block?
Column-oriented databases are helpful for some things. They are not the only solution to the problem out there. And they are still relational. Hint: They are still based on Edgar Codd's relational mathematics.
I don't doubt that there are legal obstacles to fully open source drivers. However, I was mostly trying to use nVidia as an example of concrete, practical problems with closed source drivers.
:-)
With nVidia, I think that people like to blame them too much, but they do make a good example of the problems of closed source drivers on something like Linux.
On the other hand, maybe it is time we start petitioning SGI to allow an open soure driver for the nVidia cards
How many processor architectures does it support?
If you read my journal, you will see that I am hardly the Stalin^H^Hlman type. I tend to think that we should be looking at pragmatism as a foundation of idealism not the other way around.
THe basic issue, however, is that nVidia drivers generally (at least in my experience) tend to require more effort to get installed than they should if you start to move outside of the most common process ro configurations. For example, on one of my Fedora boxes, I can get a kernel that works well with my processor or a precompiled 3d video card driver. I cannot get both. This gets worse as you move away from IA32/64 architectures.
So if you want every Linux user to be able to *easily* use the driver, it *needs* to be open source.
I thought MS bought Hotmail in 1997, but kept running it on FreeBSD until sometime in 2000 simply because nobody could figure out how to migrate that sort of environment over.
I see beauty.
I see color and sound, anger, love, and all kinds of things for which there is no logical cause or process.
I do not see a mythical sky-god. Funny, Odin looks like a sky god. But what is he really? The Indo-Europeans were not nature-worshipers-- their religion was centered around human and social concepts.
The etymology of the name suggests Odin is a mythical mind-god primarily (Odin, from Odhr + inn, meaning "master of Odhr." Odhr means song, frenzy, inspiration, or madness. Calvert Watkins (linguistics professor and author of "How to Kill a Dragon") translates "Odin" as "the incarnation of shamanic wisdom." Note, however, that this is the wisdom of a madman (compare with the Irish story of "The Frenzy of Suibhne").
The Indo-European traditions were very human-centered traditions. We were not here to serve gods, but rather there was a symbiosis between the divine and the human in this view. The religions appear to have evolved organically as an almost philosophical approach to understanding abstract social concepts. If you doubt this, note that today, there are Roman goddesses which stand in our government buildings which represent some those concepts (Libertas and Justitia), and their names, translated into Modern English are in our Pledge of Allegiance.
Furthermore Indo-European mythic chronology is very modernist. There is an idea in Indo-European mythic structures that humans are supposed to try to make the world a better place. This can be contrasted with the Abrahamic (perhaps originally Zoroastrian) structure which supposes that the world has fallen from grace and will be redeemed in its destruction.
My suspicion is that the Indo-Europeans probably evolved from an agrarian people who worshiped a sky-father ( -> Greek Diu-Piter) and an earth goddess. However two things occurred together which changed all this:
1) They acquired bronze technology
2) They domesticated the horse or acquired domesticated horses.
From these came a third: They invented the spoked wheel which quickly revolutionized their society. They probably suddenly became wealthy and developed a class of philosopher-priests who began to approach these things and guide (through a warrior who was deemed most worthy) the adminitration of justice. There is more to the story than this, but it is what my research has lead me to conclude.
My reading of Plato suggests that he largely took ideas from mythology and framed them in philosophy.
Science is an ontological process. Neoplatonic philosophy had a different ontological process. Quakerism has yet another ontological process. None of these process can work without a guiding philosophy beyond the process itself. In short, since theory is never functionally dependant on data (even when factoring in process), two people can always look at the same data and see different reasons why.
Hence science *never* tells us why something works. We can only create theories which are falsifiable.
And ancient philosophies have a way of coming back to haunt us. "Fire is the prima materia" (paraphrased from Heraclitus) is simply a cruder version of "E = mc^2" (or at least so says Heisenberg in "Physics and Philosophy").
The people who suggest (like Hitler but unlike Heisenberg, Einstein, and others) that science will outmode religion have yet to come up with a convincing explenation why so many scientists are deeply religious. More likely religion is a fundamental part of the human condition, not a mere construct of faith but a way of describing and explaining certain experiences beyond what normal language is able to convey. I do not believe that there is "one" true religion as the Christians believe, or even one perfect religion as the Muslims do. Instead, I believe that every religion is a combination of that spark of human experience (perhaps the peak experiences A. Maslow wrote about are a subset), fleshed out by culture and tradition until it forms a language (and political structure, and the like). As I am more interested in the language.
My religion is that of the scholar in search of the distant unifying principle behind the earliest Indian religious writing, and related traditions from Europe (Celtic, Greek, Norse, Old English). My practices are Norse pagan for the most part.
When we devote ourselves to logic, we ignore the fact that our brains are not wired to be strictly logical. Instead our brains are generally image-oriented and one cannot conceive of a negative without imagining its opposite, so one must understand that words like "no" or "not" tie us to the images that we seek to distance ourselves from. True mastery over ourselves requires mastery over logic, but also an ability to move beyond it to build a more powerful image of the universe within our minds.
Oh, and news flash:
#2 not everyone agrees with you (matter of fact, some people regard mainstream religion as highly offensive and insulting),
#3 just because someone disagrees with you, doesn't mean they're 'wrong'. BUt if everyone agrees with me, evidently anyone who might disagree with me would be wrong
(Please reread the summary and TFA before replying to this post)
I noticed this a few years ago in my religious and mystical studies. I noticed that we don't have a capacity to think in negative images, and hence when one states a negative (i.e. "Saddam didn't plot 9/11") the image which one visualizes is that of the opposite of the stated goal. It confirms that our brains are not logical in operation but rather use some other form of processing and storage.
One of the interesting challenges is then that one must counter this sort of thing with active imagery. For example, "Al Qaeda targetted Saddam as well as the US."
Interestingly, I suspect that, when you look at traditional Indo-European liturgical works, many structures in the poems seem to indicate an awareness of this concept. For example, a most of the uses of negative elements seem to occur as supplimental to the positive images, reinforcing those positive images (i.e formulas like "bound an not bound")
The GPL is about restricting the freedom of developers so as to provide more freedom for users. The BSD license is the other way around. But there are a lot more users than developers.
I think you are missing my point. The GPL2 I thought was a *good* balance between enforced reciprocity and freedom. While BSDL communities can provide some incentives for contributing back, the GPL2 was a *safer* bet for businesses doing an initial release.
;-)
However, my point was about the GFDL. The FDL allows authors to restrict freedom of downstream recipients to a level that even Debian feels is beyond the point of Free Software. The reason for this change was a desire for *forced advocacy* in versions of the Emacs manual. This sort of forced advocacy was exactly why Debian does *not* consider FDL documentation to be automatically Free (any invariant sections make the work unFree).
Do some research on what RMS had to say about the reason for the invariant sections clause and then come back to me
The GPL3 has other issues....
Unrestrained competition does not generally promote freedom; it generally promotes feudalism. No, I'm not joking. Half the point of government intervention in markets is to deal with market failures: situations where an unrestricted market does NOT generate an optimal result. Health care, transportation, and utilities are all examples where unregulated systems invariably lead to abusive oligarchies. (This is not to say that regulation is perfect, obviously, but we could spend lifetimes arguing economics. ;))
So you really want to spend your money trying to lock customers out of modifying your box? Someone else can spend less, provide the same features, and not have to do this. And since they have access to the code, it is sort of stupid to even try.
However that's not especially relevant to the GPL; nobody is forcing the GPL on anyone, they're merely providing it as the license they encourage people to use.
Nor does the GPL really prevent Tivoization.
Suppose I create a Tivoized box with GPL3 software. It works in the following way:
1) The loadable boot image is digitally signed. No digital signature, we don't load. The boot image contains the master OS w/hypervisor, VM-based portions which provide control over large portions of the hardware, etc. This image can only be upgraded as a unit.
2) I also provide the GPL sourcecode and instructions for getting it to run on the bare hardware. It also comes with an encryption key which is different from the one I sign my code with. That way, we always know whether the code is really unaltered ro not for support cases.
3) All access to services, automated or otherwise, require a handshake to determine that the OS is unaltered.
Now, you can compile the object code, get it to run without interference, etc. However, because you are lacking the hypervisor and related components, you can't really use the box for its intended purposes. HDTV is no longer accessible. Maybe even the coax input doesn't work because *that* is managed in a virtual environment.
We could even supply (and even require) a hypervisor that doesn't allow for direct access to these components, forcing the user to reverse engineer the whole thing in a different OS vm. Since that other component onl
Are you saying that people who are not competent to enter into contracts cannot, say, redistribute OpenBSD?
I would think that even if you look at bare license as a contract, it is different than other forms of contracts.
Finally I would point out that common law only covers 49 of the states in the US.
IANAL though.
Even so, if you have permission to do something unconditionally it doesn't matter on what legal basis this is evaluated.