В программе, которую пишу есть разные типы организаций (бюджетные, коммерческие и так далее). У каждой из этих организаций есть счета. Например у любой коммерческой организации есть счет, состоящий из счетов c номерами (01, 02, 08, 10 ...), для бюджетной (302/11, 105, 508 ...). То есть тип организации напрямую влияет на список счетов.
Вопрос в следующем - как правильно хранить эти счета в базе?
(1) (например для коммер орг в таблице будут столбцы): organisation_id, n_01, n_02, n_08 ....
(2) (Или всего три столбца) organisation_id, check_name, value
Какой вариант предпочтителен? Если по первому варианту, то для каждого типа организации будет своя таблица со счетами и, соответственно, разным количество полей. По второму варианту, как мне кажется, будет большой объем, да и вопрос по целостности данных, т .е, что есть забыли создать поле с определенным номером.
Толстый Лорри, Это понятно. Вопрос в другом, какой вариант наиболее часто используется и по скорости будет норм. И что Вы имеете ввиду "таблица со счетами"? Как она устроена?
какой вариант наиболее часто используется и по скорости будет норм
Возможно, я вашу задачу понял не полностью. Если речь про РСУБД, то:
Если количество и состав счетов меняется, то хардкодить их столбцами - не самая лучшая идея. Как с точки зрения производительности, так и памяти.
Создавать таблицы под каждую организацию - это тоже такое себе решение.
что Вы имеете ввиду "таблица со счетами"? Как она устроена?
Вроде этого
CREATE TABLE Organizations (
Id INT IDENTITY(1,1),
Name NVARCHAR(50) NOT NULL,
CONSTRAINT PK_Organizations PRIMARY KEY CLUSTERED (Id)
);
CREATE TABLE Accounts (
Id INT IDENTITY(1,1) NOT NULL,
OrganizationId INT NOT NULL,
CONSTRAINT PK_Accounts PRIMARY KEY CLUSTERED (Id),
CONSTRAINT AccountsOrganization FOREIGN KEY (OrganizationId)
REFERENCES Organizations (Id)
);
Возможно, еще нужна таблица отдельно с типами счетов.
Толстый Лорри, Будет Реляционная база. Структура счетов не будет меняться. На самом деле всего будет порядка 4 типов организаций. Количество счетов не более 20.
Простой
