On Fri, 22 Apr 2005, David Lloyd wrote:
>> Again, how do you construct this SQL statement? Think about it.
>>
>> DELETE FROM Foo WHERE ...
>>
>> Fill in the "...".
>
> DELETE FROM Foo WHERE food_id=1;
You just deleted _all_ of the records where foo_id is 1! I asked for a
way to delete just X of Y. This can't really be done without some sort of
pseudo-procedural operator, or an operator designed for multi-sets (aka
bags), as opposed to sets.
> ...and no I don't care -which- one is deleted. For example, if I order a
> pizaa over the phone, I don't care where the cheese comes from. I'd
> hardly say to the operator "Can you ensure the mozarella cheese comes
> from the cow named Daisy in Farm 666?".
In which case the pizza and its toppings would be modelled like this,
perhaps:
Pizza
-----
pizza_id - PK
ordered_by_entity_id
size_id
PizzaTopping
------------
pizza_id - PK
topping_id - PK
quantity - defaults to 1
Topping
-------
name - PK
quantity_in_stock
Of course, this supports my point, which is that duplicates don't make
sense. What would it mean for the same topping to appear twice on a
pizza? Instead, we measure _how much_ of a topping appears, which makes
updates and reporting easy. If you call back and change your order to add
double onions:
UPDATE PizzaTopping SET quantity = 2 WHERE pizza_id = X and topping_id = Y
UPDATE Topping SET quantity_in_stock = quantity_in_stock + 1 WHERE topping_id = Y
Yes, this doesn't capture the source of the cheese, but that's clearly
outside the scope of this database, and therefore not part of the business
rules we're trying to enforce. It's ok to leave out information from a
database. That's different from not enforcing basic required constraints.
>>>> It does matter. If you think it doesn't you need to learn more
>>> about > the foundations of relational databases (aka set theory and
>>> predicate > logic).
>
> You might try not insulting me next time. For that matter, if you think
> your point is valid and that I'm missing something, you could provide me
> with some links that explain your point or a better place for me to
> discuss it.
How is that an insult? I don't intend to be insulting, but it's obvious
from this discussion that you don't really understand set theory and
predicate logic, at least as it's been applied to databases in the form of
the relational model.
This is not academic abstract theory. Knowing what SQL is and isn't is a
very useful thing if you have to work with it a lot (as I do). This
knowledge will help you do better modeling, help understand why various
problems occur in badly designed databases, etc.
>> You chose to use a SQL database. Rather than accepting its failings
>> (like the fact that it doesn't require keys), you should educate
>> yourself about these problems and then realize that you should always
>> define a key. Alzabo enforces a bit more of relational theory than
>> SQL, which is a good thing.
>
> I'm working in the real world here where I have other databases,
> developed by other people that display what you term as failings of SQL
> databases. I'm not working in an academic world where I can force every
> single person, thing or entity I transact with to be "perfect".
Neither am I. Alzabo is not really designed to be fitted onto existing
badly designed databases, and you'll probably have to struggle a bit to
get it to work with them. I wrote it mostly for use with new projects, or
existing projects that weren't seriously broken.
>> If you really don't like that, Alzabo is not the right tool for you.
>
> ...or I work around what I perceive as -its- shortcomings.
The point is that Alzabo is designed the way it is for a specific reason.
I'm not going to change Alzabo to no longer require a primary key for all
tables. That would defeat one of its purposes, and would not be fixing a
bug IMO.
-dave
/*===================================================
VegGuide.Org http://www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
|