[thelist] SQL - Foreign Key Constraint - in another database?

Joel D Canfield joel at spinhead.com
Sat Sep 1 17:21:20 CDT 2001


For the record, as I got into it last night, ended up doing exactly what you
suggest. Toyed (briefly) with the idea of duplicate employee tables, but my
job is to make things easier, not more complicated.

Finished it up last night, tested primary functions, and all is well now.
Not nearly the huge task I expected (except for an hour lost to
troubleshooting a COM object because the old db called the table 'employee'
and the new one calls it 'employees' and I was looking for permissions or
other errors instead of typos.)

Thanks for the tips; helps validate that I'm not heading down the wrong path
(yet.)

Joel

<tip type="database naming conventions">
Establish naming conventions for your databases, and ensure that all
databases, fields, tables, stored procedures, etc. conform. It helps with
the portability and reusability of code and data, and is a bit of a memory
aid; when you know, for instance, that tables are always named in the
plural, you don't have to struggle to remember if it was 'employee' or
'employees' and can focus on the task rather than the minutiae.
</tip>

-----Original Message-----
From: thelist-admin at lists.evolt.org
[mailto:thelist-admin at lists.evolt.org]On Behalf Of rudy
Sent: Saturday, September 01, 2001 12:52 PM
To: evolt thelist
Subject: Re: [thelist] SQL - Foreign Key Constraint - in another
database?


> Later, built a 'grand scheme' core db for other ongoing
> purposes, which also included employee info.

hi joel

sounds like a "system of record" concept

great idea

very au courant in data warehousing

> PO app needs to reference the employee table in the
> new db now, but foreign keys from two tables point to
> the original employee table.

you *could* maintain two employee tables, but i would recommend against it

> I'm thinking my only solution is to remove said constraints,
> move the tables to the new db, then create new constraints.

may i suggest a variation

1. incorporate data from the original table into the "grand scheme" one
2. remove constraints
3. create new constraints
4. drop original table


rudy


---------------------------------------
For unsubscribe and other options, including
the Tip Harvester and archive of TheList go to:
http://lists.evolt.org Workers of the Web, evolt !





More information about the thelist mailing list