При проектировании таблицы поиска (enum) в SqlServer 2005, если вы знаете, что число записей никогда не будет очень большим, следует ли вам использовать tinyint вместо int? Больше всего меня беспокоит производительность, особенно эффективность индексов.
Допустим, у вас есть эти репрезентативные таблицы:
Person
------
PersonId int (PK)
PersonTypeId tinyint (FK to PersonTypes)
и
PersonTypes
-----------
PersonTypeId tinyint
PersonTypeName varchar(50)
Очевидными факторами являются размер данных и трудности с кодированием. Когда мы получаем 100 миллионов строк в таблице person, мы храним на 300 миллионов меньше байтов с tinyint, а не int, плюс пространство, занимаемое нашими индексами. Не большой объем данных, но значительный, если проектное решение применяется к десяткам больших таблиц. Конечно, проблемы с кодированием связаны со всеми этими проблемами приведения назад в код ASP.NET C # / VB.
Если мы отложим эти два вопроса, что еще вступит в игру? Будут ли запросы намного эффективнее из-за уменьшения размера страниц индекса? Или происходит какое-то дополнение, которое просто сводит на нет преимущества? Любые другие ошибки?
Я всегда лично использовал целочисленные типы, но я рассматриваю tinyint для предстоящей работы по редизайну / миграции на огромных столах, поэтому я хотел бы получить совет.
[Изменить]
После экспериментов с этим проблемы с кодированием, которые я ожидал, оказались бесполезными. Переход от int к tinyint не привел к возникновению проблем с приведением типов.