Где разместить значения по умолчанию и уникальные ограничения, код или SQL-сервер?

Question

Мы проектируем новую базу данных, и я хотел бы получить информацию о том, где разместить такие вещи, как значения по умолчанию. Есть 3 сценария:

1: новые значения, поле create_date. Должен ли столбец иметь значение по умолчанию при вставке?

2: обновленные значения, поля updated_date. Я думал о реализации триггера, который устанавливает это для getdate (), другой вариант в коде.

3: таблица стран с именем страны, должны ли мы применять уникальное ограничение непосредственно к таблице или убедиться, что код выполняет это?

и, наконец, немного о теме, но у нас также есть updated_by и create_by (int) в каждой таблице, которая ссылается на user_id в пользовательской таблице. Стоит ли усилий для реализации этого фк. ограничения на все таблицы?

Answer 1

Мои лучшие практики:

• Для созданных / последних обновленных дат зависит от того, если вы собираетесь использовать они как часть вашей бизнес-логики - если они предназначены только для аудита, используйте отметку времени в базе данных. Если есть шанс, что вы захотите выставить их как бизнес-недвижимость, они должны быть назначены в коде.

• Уникальные ограничения - я реализую их как в базе данных, так и в коде. Это пример базы данных, поддерживающей правила валидации, не повредит, что они определены в обоих местах. Определение кода должно перехватывать и обрабатывать их, но в случае, если код не может что-то перехватить, необходимо, чтобы ограничение безопасности ограничивало повреждение данных.

Answer 2

Положите как можно больше в базу данных. Вы по-прежнему можете манипулировать / просматривать из своего приложения, если это необходимо, но это помогает как с целостностью данных, так и с будущими версиями приложений (т. Е. Вам не придется копировать логику для вашей версии веб-приложения в будущем).

Answer 3

Ограничения должны быть в базе данных как минимум. Если вам нужно скопировать их в коде (или вывести их из базы данных), чтобы обеспечить лучший пользовательский опыт, пусть будет так.

База данных должна быть согласованной. Я потратил столько времени на отслеживание проблем, которые являются результатом «неверных данных».

Чтобы решить эту проблему, добавьте соответствующее ограничение и исправьте приложение, создавшее недопустимые данные. Я бы предпочел иметь 10 билетов, потому что кто-то не может сохранить счет (легко прослеживаемый), чем один билет, потому что отчет каким-то образом получил странное значение, связанное с неверными данными счета.

Answer 4

1. create_date, updated_date : Если это чисто столбцы аудита, показывающие изменения и кем - триггер уместен. Если ваша модель данных использует эти данные (возможно, запись с последней обновленной датой считается текущей), то ваше приложение должно это сделать. Затем ваше приложение может принимать решения о том, что должно быть текущим, вместо того, чтобы жестко закодировать его в схему, которая является «последней вставленной записью, согласно текущим настройкам часов сервера».

2. Таблица стран : Да, используйте уникальное ограничение. Ваши данные (и, следовательно, ваши запросы) не будут иметь смысла без них ... вы получите неожиданные совпадения соединений и не сможете обеспечить ссылочную целостность. Ваше приложение может надежно зависеть от того, какое оно будет иметь уникальное имя (например, путем сохранения их в SortedList).

3. Внешний ключ к таблице пользователя Да. Если стоит сохранить данные в первую очередь, стоит убедиться, что они действительны.