SQL-соединение по Int для таблицы поиска десятичных значений

Question

Я делаю проект в ядре asp.net 2.1 (EF, MVC, SQL Server) и у меня есть таблица с именем Orders, которая в итоге будет сеткой (т. Е. Бухгалтерской книгой) сделок и различных расчетов наэти цифры (без пейджинга ... поэтому можно запускать сотни или тысячи записей).

В этой таблице Orders содержится свойство / столбец с именем Size.Size в основном будет стоить от 0,01 до 10,0 с шагом 0,01..так 1000 различных значений для начала, и я предполагаю, что 95% людей будут использовать значения меньше 5,0.

Так что изначальноЯ подумал, что буду использовать OrderSize таблицу соединений, например, с ограничением FK для таблицы Order на Size (i.e. SizeId):

SizeId (Int)   Value (decimal(9,2))
1              0.01
2              0.02
...etc, etc, etc...
1000           10.0

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

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

Я предполагаю SizeId Int для объединения используется 4 байта?тогда еще 5 байтов для фактического десятичного значения?Я даже не уверен, что экономлю много места?

Я понимаю, что оба метода, вероятно, будут работать нормально, особенно для небольших запросов?Тем не менее, что является технически правильным способом сделать это?И есть ли другие ошибки или нет, которые я должен учитывать при расчете значений сетки, как вы сделали бы в бухгалтерской книге (т. Е. Предполагая, что join - это путь)?Спасибо!

Answer 1

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

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

Вам также придется учитывать индексы в таблице Orders при присоединении к таблице OrderSize, если вы решите пройти по этому маршруту. Это может привести к более частому сканированию индекса, если ключ соединения не является частью индекса в таблице Orders, что приводит к снижению производительности запросов.