[thelist] XML in database fields

I was originally going to send this offlist, but I think I may have been
a little unclear in my original post.

> the only thing is, you lose referential integrity this way. How can
you
> ensure that the product id refers to an actual product?

I suppose that if someone wanted to fool with the construction of the
page they could. If they wanted to save the HTML output to their local
drive, edit the values of the product ids inserted upon construction of
the page, they could really screw up the application. Of course, I
rarely spend my weekends going to amazon and trying to mess with their
system. Maybe I should try that.

Realize that the tables I mentioned were only part of the schema. I
assumed that people would realize that TAXCATEGORY_ID and PRODUCT_ID
were foreign keys to other tables.

> What about the
> TaxCategory_ID? what about manipulating the quantity of the item in
> question? How do you find a specific item within a cart?

<quote src="original post">
As you can see, we just eliminated the fields: ID and CART_ID. You would
probably want to employ some middleware to take care of adding products
to the cart that already exists in the cart (i.e. incrementing the
quantity -- but the hard part is checking to see if the product exists
in the cart).
</quote>

The main point of the tip was to suggest that you could create compiled
components to handle things that the database would otherwise handle and
you could eliminate fields and tables. Basically, I see it as a transfer
of responsibility from the database to compiled middleware. I also see
gained flexibility with custom attributes... that is, attributes that
apply only to one or two products. Normally, a mess of tables would have
to be built to handle such custom attributes. However, the flexibility
and beauty of strings is: you can just make them longer.

> My point is doing something this way may introduce a lot of extra
coding
> that you could be done by the db if it was its own table.

And my point is that it also intoduces possibilities and the extra
coding is a minimal downside.

> now, pulling the data outta the second table (CARTITEMS) and sending
it to
> the browser in XML and doing some client side presentation with it
(being
> able to sort, add, delete, etc) and then sending the XML back to the
server
> to be parsed and inserted to the table would be a good use of XML ...

And of course all current browsers perfectly handle XML + XSL/CSS.

> (of course, all this is my opinion, and I'm not going to disown you if
you
> do something this way)

Good to know :)



--
Matt Warden
http://mattwarden.com
me AT mattwarden DOT com