Добавляет зарезервированные поля для будущих значений хорошая идея

Question

У меня есть таблицы как Customer, Purchase и т.д., которые иногда связывают документы с ними, под документами я имею в виду какой-то файл (например, отсканированные водительские права или что-то в этом роде)

Мы не можем заставить приложение загружать эти документы прямо в базу данных, поэтому вместо этого у меня есть столбец уникального идентификатора для них (Должен ли я вместо этого иметь хэш файла?)

Мой вопрос:
В будущем у нас может быть больше документов, связанных с таблицей, поэтому я подумывал добавить дополнительные поля, такие как:

Покупатель
+ DriversLicenseDoc
+ Document1 // на будущее
+Document2 // будущее использование

Так что в будущем, если они решат, что им нужен еще один документ, мне просто нужно обновить мою модель сущности-структуры и переименовать столбец в моей модели, и базу данных не придется менять?

Это как обычно это делается? Есть идеи получше? Недостаток, который я вижу, заключается в том, что мне придется сохранять все эти будущие ценности обнуляемыми? Может быть, это не оборотная сторона?
Также хотелось бы услышать мысли о том, как вы обычно справляетесь с изменениями в схеме базы данных после развертывания?

Answer 1

Нет, это действительно плохая идея. Либо вы правильно предвидите использование, и в этом случае добавьте их так, как они должны быть, или вы просто гадаете, что может произойти, и в этом случае вам следует подождать, пока вы не узнаете.

Способ обработки изменений схемы после развертывания состоит в изменении схемы (и любого связанного кода) после развертывания. Вы должны заглянуть в аббревиатуру "ЯГНИ". По моему мнению, любые усилия, которые не нужны немедленно, следует рассматривать как усилия, предпринимаемые для чего-то, что может никогда не понадобиться. Другими словами, потраченные впустую усилия.

Если у вас есть неизвестное количество документов, которые могут существовать, это простое отношение "один ко многим" от таблицы клиентов до таблицы документов, где каждый документ в таблице содержит тип документа и полезную нагрузку документа, что-то вроде:

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

Таким образом, у каждого клиента может быть столько документов, сколько вы пожелаете, столько типов, сколько вам нужно.