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

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

0 голосов
/ 19 декабря 2010

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

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

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

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

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

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

1 Ответ

4 голосов
/ 19 декабря 2010

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

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

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

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

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

...