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

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

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

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

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

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

10.12.2008 17:44:21
4 ОТВЕТА
РЕШЕНИЕ
  1. create_date, updated_date : если это столбцы аудита, показывающие изменения и кем - триггер уместен. Если ваша модель данных опирается на них (возможно, запись с последней обновленной датой считается текущей), то ваше приложение должно это сделать. Затем ваше приложение может принять решение о том, что должно быть текущим, вместо того, чтобы жестко закодировать его в схему, которая является «последней вставленной записью, в соответствии с текущими настройками часов сервера».

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

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

3
10.12.2008 17:57:44
Кроме того, наложив на нее уникальное ограничение, база данных может знать, что вы вернете одну строку надежно и будете использовать ее при составлении планов.
WW. 11.12.2008 09:51:10

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

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

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

5
10.12.2008 17:53:46

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

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

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

3
10.12.2008 22:05:37

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

3
10.12.2008 18:01:12
Мои мысли точно - просто наличие этих ограничений в вашем приложении оставляет дверь для любого, кому удается каким-либо образом напрямую подключиться к вашей базе данных ... размещение их в самой базе данных накладывает ограничения на базу данных, независимо от того, как пользователи подключаются к ней - БОЛЬШОЙ ПЛЮС!
marc_s 7.01.2009 06:52:56