имеет ли смысл использовать int вместо char или nvarchar для столбца дискриминатора, если я использую его также как FK

Question

У меня есть что-то вроде этого:

    create table account
    (
       id int identity(1,1) primary key,
       usertype char(1) check(usertype in ('a', 'b')) not null, 
       unique(id, usertype)
    )

    create table auser
    (
       id int primary key,
       usertype char(1) check(usertype = 'a') not null, 
       foreign key (id, usertype) references account(id, usertype)
    )

    create table buser
    (
    ... same just with b
    )

вопрос: если я собираюсь использовать int вместо char (1), будет ли он работать быстрее / лучше?

Answer 1

это не имеет значения в большинстве современных баз данных. int в порядке.

символ также.

(когда база данных извлекает данные из таблицы, размер не в байтах ....)

Answer 2

Символ (1) равен 1 байту, тогда как целое число равно 4 байта. Даже маленький int равен 2 байта.

Answer 3

Зачем вам нужны столбцы IDENTITY: "auser.id" и "buser.id", которые возвращают внешний ключ к столбцу идентификации "account.id" ?? Кажется, трудно убедиться, что все когда-либо может быть синхронизировано? Когда вы вставляете в учетную запись, вы получаете ID (скажем, 1) и вводите «a», когда вы вставляете в «auser», вы получаете id (1) и FK для «account», как вы вставляете в «buser» (и получаете id 1) и fk обратно на счет 1, b ??

На реальный вопрос. Размер UserType: сколько значений у вас будет, если у вас будет всего несколько символов CHAR (1), ваш индекс будет занимать меньше памяти. если у вас будет больше, чем может удержать char (1), используйте крошечное int (0-255, 1 байт), если вам нужно больше, перейдите smallint (32k, 2 байта), если вам нужно больше, введите int (2 147 483 647, 4 байт)