Насколько важны таблицы поиска?

Ответ 1

Ответ зависит немного, если вы ограничены небольшими системами регистрации в MyNonSQL, или если вы думаете о SQL и больших базах данных.

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

Несмотря на то, что люди, которые пытаются изменить определение "нормализации" и т.д. в соответствии с этой целью, нормализация не изменилась.

• если в таблицах данных повторяются "Открытые" и "Закрытые", что является простой ошибкой "Нормализация". Если вы измените эти значения, вам может потребоваться обновить миллионы строк, что очень ограниченно. Такие значения обычно нормализуются в таблицу Reference или Lookup. Это также экономит место. Значение "Открыть" , "Закрыто" и т.д. Больше не дублируется.

• вторая точка - легкость изменения, если "Закрыто" было изменено на "Истек", снова необходимо изменить одну строку и это отразится на всей базе данных; тогда как в ненормализованных файлах необходимо изменить миллионы строк.

• Добавление новых значений - это просто вопрос о вставке одной строки.

• в терминах Open Architecture таблица Lookup является обычной таблицей. Он существует в каталоге (стандартный SQL); любой инструмент отчета может найти его, если определено отношение PK:: FK, инструмент отчета также может найти это.

• Enum предназначен только для не-SQLS. В SQL Enum является таблицей Lookup.

• Следующий момент касается значимости ключа. Если Ключ не имеет смысла для пользователя, в порядке, используйте INT или TINYINT или что-то подходящее; число их постепенно; разрешить "пробелы". Но если ключ имеет смысл для пользователя, не используйте бессмысленное число, используйте значащий ключ. "M" и "F" для мужчин и женщин и т.д.

  • Теперь некоторые люди попадут в касательные к постоянству ПК. Это отдельная точка. Да, конечно, всегда используйте стабильное значение для ПК. "M" и "F" вряд ли изменится; если вы использовали {0,1,2,4,5,6}, ну не меняйте его, зачем вам это нужно. Эти ценности должны были быть бессмысленными, только значимый ключ должен быть изменен.
    ,

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

• Так как PK стабильны, особенно в таблицах Lookup, вы можете безопасно закодировать:

  WHERE status_id = 'O'

  Вам не обязательно присоединяться к таблице Lookup и проверять значение "Открыть" . Это теряет значение таблицы Lookup в сегментах кода.

SQL - это громоздкий язык, особенно когда речь идет о объединениях. Но это все, что у нас есть, поэтому нам нужно просто принять обременение и разобраться с ним. Ваш примерный код в порядке. Но более простые формы могут делать то же самое. Инструмент отчета создаст:

SELECT  p.*,
         s.name
    FROM posts p, 
         status s
    WHERE p.status_id = s.status_id 
    AND   p.status_id = 'O'

• Для банковских систем, где мы используем короткие коды, которые имеют смысл (поскольку они имеют смысл, мы не меняем их с помощью сезонов, мы просто добавляем к ним), учитывая таблицу Lookup, такую ​​как (тщательно подобранная, аналогично кодам стран ISO):

  
  Eq   Equity
  EqCS Equity/Common Share
  O    Over The Counter
  OF   OTC/Future

  Обычно такой код:

  WHERE InstrumentTypeCode LIKE "Eq%"

И пользователи будут выбирать значение из раскрывающегося списка, которое отображает "Открыть" , "Закрыто" и т.д., а не {0,1,2,4,5,6}, а не {M, F, U }. И в приложениях, и в инструменте отчетов. Без таблицы поиска вы не сможете этого сделать.

В последнем случае, если база данных была большой и поддерживала функции BI или DSS или OLAP (в большинстве нормализованных баз данных), тогда таблица Lookup на самом деле представляет собой измерение или вектор в анализе измерений. Если его там не было, тогда его нужно будет добавить, чтобы удовлетворить требования этого программного обеспечения, до того, как такие анализы могут быть установлены.

Ответ 2

Для справочных таблиц я использую разумный первичный ключ - обычно просто CHAR (1), который имеет смысл в домене с дополнительным полем Title (VARCHAR). Это может поддерживать принудительное соблюдение отношений, в то время как "поддержание простого SQL". Ключ, который нужно запомнить здесь, - это таблица поиска не содержит данные. Он содержит тождества. Некоторые другие идентификаторы могут быть именами часовых поясов или назначены коды стран МОК.

Например, пол:

ID Label
M  Male
F  Female
N  Neutral

select * from people where gender = 'M'

В качестве альтернативы ORM можно использовать, и ручное генерирование SQL, возможно, никогда не должно быть выполнено - в этом случае стандартный подход "суррогатного ключа" "int" прекрасен, потому что с ним что-то имеет дело: -)

Счастливое кодирование.

Ответ 3

Создайте функцию для каждого поиска. Нет простого способа. Вы хотите простоту производительности и запросов. Убедитесь, что поддерживается следующее. Вы могли бы создать SP_TestAppEnums, чтобы сравнить существующие значения поиска с функцией и искать вне синхронизированного/нулевого значения.

CREATE FUNCTION [Enum_Post](@postname varchar(10))
RETURNS int
AS
BEGIN
DECLARE @postId int
SET @postId =
CASE @postname
WHEN 'Open' THEN 1
WHEN 'Closed' THEN 2
END

RETURN @postId
END
GO

/* Calling the function */
SELECT dbo.Enum_Post('Open')
SELECT dbo.Enum_Post('Closed')

Ответ 4

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

• довольно статичный характер; домен может расширяться, но он, вероятно, не будет сокращен.
• их первичные ключевые значения также вряд ли могут измениться (например, статус_id для статуса "open" вряд ли вдруг изменится на нечто иное, чем то, что было создано как).

Если приведенные выше допущения верны, нет никакой реальной необходимости добавлять все эти дополнительные таблицы в ваши объединения, так что предложение where может использовать имя друга вместо значения id. Просто фильтруйте status_id прямо там, где вам нужно. Я подозреваю, что неключевой атрибут в предложении where ( "имя" в приведенном выше примере) скорее всего получит изменения, чем ключевой атрибут ( "имя" в приведенном выше примере): вы более защищены, ссылаясь на ключа (ов) желаемого в таблице домена в вашем соединении.

Доменные таблицы обслуживают

• чтобы ограничить область переменной посредством отношения внешнего ключа,
• чтобы разрешить расширение домена путем добавления данных в таблицу домена,
• для заполнения элементов пользовательского интерфейса и т.д. с помощью удобной для пользователя информации,

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

YMMV: многое зависит от контекста и характера проблемного пространства.

Ответ 5

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

Я думаю, что константа здесь подходит, а таблица базы данных - нет. Когда вы разрабатываете свое приложение, вы ожидаете, что таблица статусов никогда не изменится, поскольку ваше приложение имеет жестко закодированное в нем, что означают эти статусы. Точка базы данных заключается в том, что данные внутри нее будут изменены. Бывают случаи, когда линии нечеткие (например, "эти данные могут меняться каждые несколько месяцев или около того..." ), но это не один из нечетких случаев.

Статусы являются частью вашей прикладной логики; используйте константы для определения их в приложении. Это не только более строго организовано таким образом, но также позволит значительно ускорить взаимодействие с базами данных.

Ответ 6

По возможности (и это не всегда...), я использую это эмпирическое правило: если мне нужно жестко закодировать значение в моем приложении (и пусть оно останется записью в базе данных), а также сохраните это vlue в моей базе данных, тогда что-то не так с моим дизайном. Это НЕ ВСЕГДА истинно, но в основном, независимо от того, что имеет значение, оно представляет собой часть DATA или фрагмент PROGRAM LOGIC. Это редкий случай, что это и то, и другое.

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

Лично, однако, я стараюсь стоять на своем правиле выше. Это либо DATA, либо PROGRAM LOGIC, либо редко. Если он заканчивается как (или IN) запись в базе данных, я стараюсь не допускать ее из кода приложения (за исключением, конечно, извлечения из базы данных...). Если он жестко закодирован в моем приложении, я стараюсь не использовать его в своей базе данных.

В тех случаях, когда я не могу соблюдать это правило, я ДОКУМЕНТ КОДА с моими рассуждениями, поэтому через три года какая-то бедная душа сможет выяснить, как это сломалось, если это произойдет.

Ответ 7

Ответ "независимо от смысла".

таблицы поиска включают объединения или подзапросы, которые не всегда эффективны. Я много использую перечисления для выполнения этой работы. его эффективный и быстрый