|
|
Posted by Michael Daly on 04/07/07 18:02
Mr. Newt wrote:
>> Obviously replace with real statements and put your error checking in.
Trying to do multiple updates without checking for errors on each one
individually is, IMHO, sloppy programming. Doing it as a transaction
with commit/rollback is advisable.
> I may be making my life harder than it needs to be. I'm writing a db for a
> friend and have never done anything this big before. So, trying to be
> fancy, I decided to try normalizing the data first.
That's not being fancy. If there's one thing I've learned over the
decades, it's that designing the database correctly up front makes life
a lot easier in the long run.
> I decided to separate
> the advertiser table from the address table, because I might add addresses
> (like mailing addresses of customers) to the address table.
Good plan - there's no reason to have multiple address fields in
multiple tables. You're likely to see this go from a one-one
relationship to a one-many as someone eventually points out that a
company can have different addresses for billing, shipping and receiving
etc. Ditto customers.
> So, that's why
> I want to be able to access/write data in more than one table at a time.
Since updating joins is problematic (some databases don't support any
updatable joins), think of this as separate updates that are related by
foreign keys. To ensure they work as a unit, use transactions and
either commit or rollback as appropriate.
Mike
Navigation:
[Reply to this message]
|