Простой вопрос по дизайну БД

Question

У нас есть 2 таблицы: FILES и FILEHISTORY, определенные следующим образом:

FILES
( FILEID INT NOT NULL PRIMARY KEY,
 FILEBODY LOB,
 FILENAME VARCHAR)

FILEHISTORY
( FILEID INT NOT NULL PRIMARY KEY,
  FILENAME VARCHAR,
 some other fields)

То есть, у истории файлов есть расширенные свойства, говорящие о том, что было сделано для файла с FILEID.

Теперь наши ребята из базы данных сделали FILEID первичным для таблицы FILEHISTORY, а FILEID из таблицы FILES ссылается на FILEID FILEHISTORY в качестве внешнего ключа. Это правильно? Не должно ли быть наоборот?

Answer 1

Если вы придерживаетесь этого подхода, предложенного вашими ребятами из db, как он учитывает тот факт, что файл может иметь несколько записей истории?

Например:

Файл A - созданный вами вчера

Файл A - изменен мной сегодня

В этом случае на основе схемы ниже: -

FILEHISTORY
( FILEID INT NOT NULL PRIMARY KEY,
  FILENAME VARCHAR,
 some other fields)

В FileHistory для файла A будет 2 записи - скажем, с FileID = 1 и FileID = 2

Вопросы -

1. Какой из 2 идентификаторов файлов (1/2 для файла А) будет сохранен в поле «Идентификатор файла» в «Файлы» таблицы?

2. В этом варианте использования идентификатора больше не будет достаточно для поиска по всей истории файла (возможно, именно поэтому FileHISTORY также имеет поле FileName, поскольку это единственный реальный способ поиска всей истории файла). файл - и это будет не так эффективно, как поиск по идентификатору вместо строки)

3. Кроме того, возможно ли, что файл может быть переименован? Если пункт 2 выше действителен, то я предполагаю, что переименование файла приведет к потере всех записей истории для этого файла.

Я пытаюсь сказать вот что:

1. Я думаю, что ваш подход к использованию fileID как первичного в таблице FILES - лучший подход. Я думаю, что это имитирует фактические отношения файлов более реалистично.

2. В зависимости от требований вашей системы, предлагаемый подход может работать, но он определенно потребует больше усилий, и есть некоторые сценарии, где он может потенциально быть более дорогим / не в состоянии удовлетворить.

Answer 2

Filehistory должно быть:

FILEHISTORY
id int not null primary key
fileid int (foreign key to files)
other fields

имя файла может быть удалено из истории файлов, поскольку оно уже доступно в файлах, которые связаны с fileid.

Эта модель позволяет одному файлу иметь несколько FILEHISTORY