On 01/30/2010 05:35 PM, Vladimir Dronnikov wrote:
> And all the above is theory. Humans just need to stick to Aristotle'
> logic, or they start to melt.
>   

It's not just theory. It is a consequence of a system with rules. Humans
also live in a system with rules and must obey them, like it or not.
Even the greatest anarchist will eventually succumb to the rules imposed
by Entropy.

So if a rule says B should disappear when A does, it is a normal state
for the system obeying those rules. The rules, however, may be imposed
by nature or man, the principle remains.



> So states the _proven_ physical law. No artificial cascading here just
> for convenience. (However, who knows, may be the higher "ratio" thinks
> in sql terms? :)
>   

Cascading on a foreign key is not a "convenience", it is a rule of
normalized relational dataset that requires informational integrity.
Whether it is "artificial" or not depends on the interpretation of
artificial.

If you do not require informational integrity then you will design your
system with no foreign keys. You can also bunch everything in a single
table and forget normalization. And therefore no relations and no
cascades. It all depends on the desires of the programmer or DBA.

Similarly with a file system. You can have indices that point where
files and corresponding sectors are. They are convenience because
without them the application would have to scan entire disc to find its
files. But a FAT table is not a convenience. It is a relation between
position of a "file" and its data on disc. Without it, the application
cannot find its data because there is no pointer to it. This is a
relation not unlike foreign keys.

That the data is not deleted when the file (pointer) is is just a matter
of performance. Secure systems that require deletion of data will delete
both the pointer and the data because it is normal operation within the
rules of the system. Nothing artificial there, just the requirements of
a system.



> Of course, if "it did require". But it didn't. So here we again try to
> impose a pure artificial constraint just to keep dataset normalized
> and thus to stick to a convenient model.
>   

You can build tables with no foreign keys and therefore no cascades. The
cascades are only there if you impose a set of rules on your tables. And
it is only as artificial as the entire IT concept: namely, nature didn't
build them, we did. Machines understand only binary. It is the dev who
gives meaning to the data and hence imposes rules so the machine can
understand the relations.

It all boils down to the rules saying: I have two tables, their rows are
related. If a row in table A is gone, the corresponding row in table B
should too. Why? Because the designer of the system sees a meaning that
the machine does not. If the machine were an AI it would probably delete
row B without the program telling it to cascade, because the machine
understood the relation (after learning of one).

Machines of nature work similarly. A simple rule says that the cell
needs power. So it happens that in the evolutionary dataset one
important relation emerged: that between mitochondria (A) and the cell
(B). It says that A provides power for B. Another rule says if there's
no A, B dies. The underlaying hardware (pure atoms and molecules)
couldn't care less and see the relation as "artificial", from their
point of view, because they don't "understand" the relation.

And if you really want to get philosophical (and I see I've gone that
way already, heh), I recommend: http://arxiv.org/abs/0801.0337 :)))


> ... which pretty certainly doesn't mean the content itself _does_ disappear 
> too.
>   

Given strong enough encryption it is as good as dead. A file with random
bits, for all that anyone without the key cares.




Vlad

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to