Re: One Ring to Bind Them

In message <CLgGc.26848$a24.25938_at_attbi_s03>, Marshall Spight <mspight_at_dnai.com> writes
>> The models we use create "stupid" tricks. It's the models that create the
>> constraints to make some tricks stupid and others smart. An RM "stupid"
>> trick may be an MV smart move; and visa-versa. However, most design and
>> development are constrained by the base delivery model: server vs
>> client/server.
>
>I disagree. There are specific well-documented and *fundamental*
>disadvantages to managing integrity in applications instead of centrally.
>This is independent of MV vs. RM vs. whatever.
>
Well, yes ...

But my experience is that that begs the question. Do you want your data to be "consistent" OR "accurate"? Constraints enforce consistency, but what do you do when real-life decides that IT is going to be INconsistent?

With flexibility comes power. MV solutions are more flexible. And with that flexibility comes the ability to shoot yourself in the foot.
>
>> > Please be specific. I am very interested in specific examples of specific
>> > operations or structures that you feel are hard to solve with RM or SQL
>> > and easy to solve with MV. I do believe there are some, but I want
>> > to know what they are better. As it stands I have a hard time evaluating
>> > the claims of the MV people, even the smart/nice ones such as you
>> > and Dawn. I'm not saying I believe, and I'm not saying I disbelieve.
>> > I just want to hear more specifics.
>>
>> Let's reconcile a bank account. We need a primary account table and a
>> transaction table in both models. However, in the MV model we don't need
>> anything more than this. We will define the keys of the transactions to
>> include the account#, so the account table can (and probably will) contain
>> the ref# of the transactions. The transaction key would look like:
>> Account# and transaction#.
>
>You're going to reuse transaction numbers in different accounts?
>And you're also going to include the transaction number in
>the account table? That kind of redundancy leads directly
>to data corruption.
>
What redundancy? MV does not normally contain redundant data. Unless you mean storing a foreign key is "redundancy", and isn't that what relational databases do all the time?
>
>> Now, what good is this? As Mr Youngman points out it only takes one disk
>> read to get the account and its relationships to the uncleared transactions.
>> This is an almost instantaneous response to our web clients. So there's an
>> upside.
>
>Ugh. Let's please not talk about disk reads.
>

So you're quite happy to give your clients a system that, running on a Cray, still makes an old Z80-based system look like a speed demon?

The whole reason we hammer on about disk accesses is because we KNOW we can't be beaten. And the whole reason relational people like you don't like it is because you can't compete. Isn't that always the rule of competition - try to make the other guy's advantage look like a disadvantage?

At the end of the day, by avoiding things like disk reads, you are saying "performance is irrelevant". Taken to its extreme, that means that you would be quite happy delivering a system that guaranteed to eg crack a 4096-bit RSA key. The fact that it wouldn't finish its first run before the heat-death of the solar system isn't your problem ...

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999