Building FK constraints depends on the application
characteristic. We have an application in which we do not have any FK
constraints. The primary purpose of this application is monitoring the
trade messages that flow from stock exchanges and match them with the stock
purchase/buy orders. Only 6 tables are in the database. But we
receive approximately 1000 to 10,000 trade messages (depending on the customer)
into one of the main tables. The average size of a trade message is 800
bytes. Once a trade is matched, the record is either deleted or archived
depending on business rules. Stored procedures validate the trade message
but they do not use any FK while inserting the data or deleting the
data.In the beginning building this kind of database gave me creeps and
later once I understood the business rules/functionality, I was convinced.
This application is running without any problem (I mean data inconsistency,
leaving orphan records in the tables etc.) and customers are using this and they
are satisfied.The database is 804 on Sun.Maheswara
RaoDBA
<SPAN
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><A
href="mailto:Maheswara.rao_at_sungardp3.com">Maheswara.rao_at_sungardp3.com
Received on Wed Mar 21 2001 - 08:15:00 CST
