Re: some ideas about db rheory

vldm10 wrote:
> On Jul 10, 4:34 am, paul c <toledobythe..._at_oohay.ac> wrote:

>> vldm10 wrote:
>>> On Jul 8, 5:30 am, paul c <toledobythe..._at_oohay.ac> wrote:
>>>> I doubt if I would get the drift of the rest of your message no matter
>>>> how hard I tried
>>> You can try at:
>>> http://groups.google.com/group/comp.databases.theory/browse_frm/threa...
>> Thanks, not sure if I had ever noticed those messages before but if I
>> had I probably would have discounted them as soon as they suggested that
>> dependencies are somehow intrinsic to the question when at most they are
>> only a way to enumerate or differentiate cases

Well, there aren't any mainstream languages that I've heard of that express FD's, for example I don't believe there is a way in SQL to specify a key in a SELECT stat;ement. Sorry to break my rule of posting when I've had more than one glass of plonk, but the above supposition would likely be easy to answer if I had ten. For some perverse reason, I have a fascination with such rhetoric because no matter how well it is replied to, nobody who reads any reply, not just mine, will understand anything more than they did before! My question would be why do you post this stuff here? There must be plenty of non-technical, social groups where the audience can make sense of any mumbo-jumbo you throw at them. I remember making many trips to one large US state where rote ruled and if some methodology or other mentioned, say, intrinsic properties, everybody involved was thereupon expected, for all time, world without end, to take care to distinguish those from the non-intrinsic properties. At one time, the cost of typewriters and the time needed to learn them made this form of illiteracy not so common.

>> (a misleading way if you
>> ask me even though I know Date uses them, maybe that's why he concludes
>> certain updates are 'unsafe'.  

I doubt if it would be 'good' for people who have spent more than the ten years or so that I spent excising phony requirements or who have studied db theory more carefully than I have (I suspect that most of those don't post nearly as often as I do) but assuming the applications step have already been done (for example, why do you think you have an app here? or what do you think your app is?), there are obvious first steps that various people might re-arrange in ways they prefer: 1) find out what answers are needed from the db, 2) find out what facts are available to infer them from, 3) reconcile the results from 1) and 2) and 4) organize the facts. Step 4) is susceptible to various techniques, normalization among them. I think Date should have not called that chapter 'database design', rather 'database implementation tools/techniques' or similar.

>> Apart from that the various 'principles'
>> that he invokes make me uncomfortable because they suggest that some
>> approaches are more 'proper' than others, somehow more 'inherent', when
>> in fact and in the first place there is no inherent insert or delete in
>>   the bare RM.  How an implementation language defines the assertion and
>> retraction of facts is closer to a matter of policy than of principle,
>> so I sometimes wish Date would say 'policy of ...', instead of
>> 'principle of ...'.  People who want to avoid mysticism need to
>> recognize the place of logic in an rdbms, where it starts and where it
>> ends.  

I don't know why you might suspect I had anything to say about truth. It does remind me that most participants here are just looking for a way to appear to fit in commercially in an immediate way and have no real interest in basic theory. In any field I know something of, that's usually the last thing I care about and here it's generally a waste of time for db practioners to talk about truth. Theory and practice trump truth in every field, including the religious pursuits and other sops to natural human confusion. Maybe it has something to do with the term 'truth-functional' and the so-frequent supposed connection from that to the word 'reality' by semi-literates who couldn't tell a field from a context. The very first question that a dbms must deal with is how (in the case of an rdbms) and to what extent logic is to be applied. There are a few reasons to use FOL in the first place, one is to re-phrase declarative statements for machine efficiency. How a supposedly popular language chooses to allow us to express ourselves to a machine has nothing to do with logic. From my experience it is a certainty that very few users will ever apply FOL to predict or prove results and they will certainly not ever graviitate to a language that requires them to express logic overtly. (I remember the only logic exam I ever had to write, at least 100 Arts students out of about 200, walked out after ten minutes. I was very impressed at how they could finish a three-hour exam so quickly! Later I knew CS professors who had never taken a logic course, let alone taught one.)

Religious theorists try to tie up logic with truth all the time and claim various forms of both for their own. To the man or woman in the street they will proclaim various self-serving 'logics' to do with propriety of some kind, usually the proper management of the most basic human motives and inescapable behaviours. The Vatican never has the guts to admit it is in basic competition with Hollywood in the sexual area, usually disguising its motives by the introduction of an essentially logical term, 'morality' and never mentioning the aspects of sexuality that don't contribute to their purpose, which has to do with expansion and control, never truth. Now, we talk here about a subject whose purpose is obviously economic, ie., commercial. It was big business centralization and accountants who got this field off the ground. What has truth ever got to do with db?

>> When they suggest a language that can retract certain facts but
>> not assert those same facts, or vice-versa, I think their language
>> definitions need some more work, to put it mildly!).

My amateur language is perhaps partly responsible, but as I suggested above, it's not all my fault and I would have hoped if you took the trouble to respond to my polemics that you would have said something about what I think is a basic scandal, the propagation of systems that go in one direction but not another. I think the db industry is very much playing the same game as the tailors of the Emperor's New Clothes, putting out systems that let people paint themselves into corners, you can insert but you can't delete, or the other way around. This is a tyranny of the technocrats if there ever was one. I read somewhere that McGoveran is writing a book which is at least in part about this. I hope to see it someday (in this rote world). Apart from that, I think you are posting this stuff to the wrong group.. Received on Wed Jul 15 2009 - 07:30:02 CEST