开发者

is adding reserved fields for future values a good idea

开发者 https://www.devze.com 2023-01-31 02:56 出处:网络
I have tables like Customer, Purchase etc which sometimes have associated documents with them, by documents I mean some file somewhere (like a scanned drivers license or something)

I have tables like Customer, Purchase etc which sometimes have associated documents with them, by documents I mean some file somewhere (like a scanned drivers license or something)

We cannot have the application upload these documents straight into the database so instead I have a uniqueidentifier column for these (Should I have a file hash instead?)

My question:

In the future we might have more documents associated with a table, so I was thinking of adding extra fields like:

Customer

+DriversLicenseDoc

+Document1//for the future

+Document2 //future use

So in the future if they do decide they want another document I will just have to update my entity-framework model and rename the column in my model and the database won't have to change?

Is this how its generally done? Any bet开发者_Go百科ter ideas? The downside I see is I will have to keep all these future values nullable? Maybe thats not a downside?

Also wold like to hear thoughts on how you generally cope with changes in database schema after deployment?


No, it's actually a really bad idea. Either you foresee the use correctly in which case add them as they are meant to be, or you're just guessing at what might happen in which case you should wait until you know.

The way to handle schema changes after deployment is to change the schema (and any related code) after deployment. You should look into the acronym "YAGNI". In my opinion, any effort that is not needed immediately should be viewed as effort carried out for something that may never be needed. In other words, wasted effort.

If you have a unknown number of documents that may exist, that's a simple one-to-many relationship from the customers table to the documents table, with each document in the table carrying the document type and document payload, something like:

customers:
    custid  primary key
    <all other customer data>
documents:
    docid primary key
    custid references customers(custid)
    <all other document data>

That way, each customer can have as many documents as you wish, of as many types as you need.

0

精彩评论

暂无评论...
验证码 换一张
取 消