Таблица справочник в базе данных как сделать

Добавил пользователь Евгений Кузнецов
Обновлено: 18.09.2024

Инструкция CREATE TABLE используется для создания новой таблицы в базе данных.

Синтаксис

Параметры столбцов задают имена столбцов таблицы.

Параметр datatype указывает тип данных, которые может содержать столбец (например, varchar, integer, date и т.д.).

Совет: Для получения обзора доступных типов данных перейдите Справочник Типы данных.

SQL Пример CREATE TABLE

В следующем примере создается таблица "Persons", содержащая пять столбцов: PersonID, LastName, FirstName, Address, и City:

Пример

CREATE TABLE Persons (
PersonID int,
LastName varchar(255),
FirstName varchar(255),
Address varchar(255),
City varchar(255)
);

Столбец PersonID имеет тип int и будет содержать целое число.

Столбцы LastName, FirstName, Address, and City имеют тип varchar и будут содержать символы, а максимальная длина этих полей составляет 255 символов.

Пустая таблица "Persons" теперь будет выглядеть так:

Совет: Пустая таблица "Persons" теперь может быть заполнена данными с помощью инструкции SQL INSERT INTO.

Создать таблицу, используя другую таблицу

Копия существующей таблицы также может быть создана с помощью команды CREATE TABLE.

Новая таблица получает те же определения столбцов. Можно выбрать все столбцы или отдельные столбцы.

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

Синтаксис

Следующий SQL создает новую таблицу под названием "TestTables" (которая является копией таблицы "Customers"):

Рассмотрим процесс создания таблиц на примере Базы данных

Код поставщика (кл)

Разработку базы данных рекомендуется начинать с создания главных таблиц.

Таким образом, в рассматриваемом примере порядок создания таблиц следующий:

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

1. В Окне навигации выбирается Категория объекта - Тип объекта, а в разделе Фильтр по группам устанавливается переключатель Таблицы. На вкладке Создание в группе Таблицы нажимается кнопка Конструктор Таблиц.

2. В появившемся окне Конструктора в столбце Имя поля перечисляются заголовки полей создаваемой таблицы, а в столбце Тип данных, выбирается их тип, создается описание (рис. 2.10).

Комментарии к выбору типов данных:

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

3. Определяются свойства полей.

3.1 Свойства поля Код поставщика (рис. 2.11).

Размер поля - длинное целое (см. табл. 2.1),

Новые значения - последовательные.

Свойства поля Код поставщика

Рис. 2.11 Свойства поля Код поставщика

3.2 Свойства поля Поставщик (рис. 2.12).

Размер поля - 100 (ограничение на количество водимых символов - не больше 100),

Обязательное поле - Да (заполнять значения поля обязательно).

Свойства поля Поставщик

Рис. 2.12. Свойства поля Поставщик

3.3 Свойства поля Адрес (рис. 2.13).

Размер поля - 150 (ограничение на количество водимых символов - не больше 150),

Обязательное поле - Нет (заполнять значения поля не обязательно).

Свойства поля Адрес

Рис. 2.13. Свойства поля Адрес

3.4 Свойства поля Телефон (рис. 2.14)

Свойства поля Телефон

Рис. 2.14 Свойства поля Телефон

Обязательное поле - Нет (вводить номер телефона пользователя в базу данных не обязательно),

Маска ввода (шаблон для ввода данных)

2 -- 2 2 2 -- 2 2 2 -- 2 2 -- 2 2

Алгоритм создания пользовательской маски ввода описан ниже.

Формат поля - @-@@@-@@@-@@-@@[Синий];”нет”[Зеленый].

формат для номера формат для текста

@ обозначает, что ввод символа обязателен,

& обозначает, что ввод символа не обязателен.

Рис. 2.15 Формат поля Телефон


Алгоритм создания пользовательской маски ввода (на примере поля Телефон)

Напротив строки Маска ввода нажимается кнопка .

В диалоговом окне Создание масок нажимается кнопка Список (рис. 2.16). В окне Настройка масок ввода заполняются все поля согласно требованиям и нажимается кнопка Закрыть (рис. 2.17). Символы, используемые в масках ввода, описаны в Приложении 1.

Созданная маска ввода появится в списке окна Создание масок. Её необходимо выделить и нажать кнопку Готово (рис. 2.18).

Диалоговое окно Создание масок ввода

Рис. 2.16. Диалоговое окно Создание масок ввода

Рис. 2.17.Диалоговое окно Настройка масок ввода

Рис. 2.18 Диалоговое окно Создание масок ввода с созданной маской ввода для поля Телефон

4. После того как все поля созданы и определены их свойства устанавливается ключевое поле.

Для этого курсор устанавливается в строку Код поставщика и на вкладке Конструктор нажимается кнопка . Таблица сохраняется.

Таблица основных данных справочника содержит информацию о стандартных реквизитах и реквизитах, которые мы добавляем в конфигураторе.

Реквизит составного типа 1С.[/caption][caption align="aligncenter" width="730"] Реквизит составного типа в СУБД

Реквизит составного типа 1С.[/caption][caption align="aligncenter" width="730"] Реквизит составного типа в СУБД

Что такое Первичный ключ

Чтобы ответить на этот вопрос, необходимо разобрать такое понятие, как первичный ключ (primary key, PK).

Primary key – это колонка, которая задает уникальность строки в таблице. Другими словами, это такая колонка, значения в которой уникальны в рамках всей таблицы, но не уникальный в рамках всей Базы Данных (БД).

Потенциальным PK называется любая колонка, которая может удовлетворять требованиям primary key. Например, ИНН, ФИО, СНИЛС, Номер паспорта, ФИО + Дата рождения – это будет потенциальный составной PK. Но у всех этих полей есть нюансы, например, какие-то их них все-таки могут дублироваться, например, ФИО, а какие-то могут быть не заполнены, например ИНН, если контрагент нам его пока не сообщил.

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

Для стабильности и надежности используют суррогатные ключи – это такие PK, которые генерируются искусственно, но имеют 100% уникальность в рамках своей таблицы. Таким образом, это позволяет указывать не полные данные, например, контрагента, а только PK его строки. А СУБД по primary key уже сможет найти все данные этого контрагента в основной его таблице.

Первичный ключ одной строки, который указывается в другой, т.е. поле одной строки имеет связь через это значение с данными другой строки, называется Внешним ключом (foreign key).

Реляционная база данных

Установка связей (relations) между таблицами через PK и FK, с целью минимизировать объем хранимых данных (чтобы не дублировать одинаковые значения) называется – нормализация (normalization).

СУБД, в которой, все таблицы нормализованы, называется реляционная СУБД, т.е. у всех таблиц установлены связи между собой и данные в БД не дублируются.

Что такое ссылка в 1С

В 1С первичные ключи являются суррогатными, генерируются по правилам GUID, и называются ссылками.

Posted via ActualForum NNTP Server 1.5

Вот тут как раз таки не очень нормально, ибо рано или поздно в таблице Сделки поле Вид сделки окажется значение, например, из справочника с типом Вид свифтовки. ЧТобы этого не произошло, придётся на таблице сделок делать триггер, который будет ходить в таблицу справочников, вытягивать тип и сравнивать с захардкоженным в триггере позволенным типом справочника для этого поля. А если в искомой таблице положим 10 справочных полей, то 10 раз долбить БД запросами на получение типа (хотя их конечно можно закэшировать, но это лишний гемор особенно с учетом обновления справочников пользователями) для одного апдейта или инсерта искомой таблицы как-то стрёмно.

2. Общий справочник, в котором иерархически (id, idParent) расположены записи.

НЕ понятно, что это вдруго иерархический.
Не должно быть там никакой иерархии.

Родитель - имя справочника, дочерние - элементы.

Имя справочника (это должен быть отдельный метасправочник) идёт в PK таблицы, там ещё будет ID. ОТкуда иерархия ?

сервера на прод надо синхронизировать структуру справочника => лишний геморой. Кроме того, в этом случае плохо работает ограничение целостности.

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

На практике есть пожалуй что один случай, когда второй вариант удобнее: это ситуация, когда справочники определяются пользователем (скажем, всякие произвольные аналитические признаки). Во всех остальных случаях это только дополнительные недостатки и дополнительный геморрой. Этот способ "нереляционный" и поэтому применение его в реляционных операциях печально. Даже просто использовать справочник в запросе - уже менее удобно, а уж добавить в справочник новое поле - задача вообще нерешаемая. В качестве побочного эффекта получим плохую эффективность запросов, поскольку оптимизатор, видя ссылку на таблицу с тысячью записей, сочтёт индекс селективным и жестоко ошибётся.

> Думаю, что справочников в системе должно быть чуть - единицы измерения,
> наименования дней недели, еще какие-то совсем общие сведения. Все остальные
> якобы "справочники" в итоге оказываются вполне обычными сущностями предметной
> области - обычно с уникальным набором данных и собственным поведением. Так что
> всегда и без исключений вариант 1.

Так надо ж сначала дать определение справочкика.
Справочник -- неизменяемая сущность предметной области.
(меняется только с предметной обласью вместе).

Posted via ActualForum NNTP Server 1.5

Даже в этом случае структуру не всегда можно уложить в шаблон "Id, Name".
У единицы измерения может быть сокращенное и полное наименование (Г,грамм), принадлежность к классу (масса), признаки (основная/не основная) и т.п.

Вариант 1 позволяет возложить многое на СУБД, как то упрощение администрирования, репликации. Вариант 2 бывает незаменим, если надо "администрировать само администрирование", и вообще если конечные "клиенты" сами воротят всякие "справочники": этот чел имеет такие-то права на эти атрибуты номенклатуры, а на эти - не имеет. Впрочем обычно НСИ в общем виде не укладывается в одну таблицу, так что и 1 и 2 бывает.

Читайте также: