Частая смена схемы БД

[AnTe]

Здравствуйте. Вопрос чайника

Для разрабатываемого ПО создаётся соответствующая БД (ORACLE). Структура БД относительно проста, но в ней имеется таблица "параметров", по которым идёт поиск нужного элемента.

Проблема в том, что кол-во параметров будет со временем расти, то есть изначально "базовых" параметров (длина ширина высота ... ) - около двух десятков, но в процессе работы будут добавляться новые

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

Вопрос в том, правильно ли будет, создав структуру базы, наполнив её данными потом в процессе работы постоянно добавлять поля к таблице (предположительно число параметров с двух десятком может вырасти до сотни)?

Является ли эта схема работы рекомендуемой ораклом, не возникнет ли каких-нибудь проблем, или таки нужно извратиться, сразу забить сотню "пустых" полей, которые потом использовать?

[Аватар]

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

[Serge_Bliznykov]

Вы изначально проектируете НЕВЕРНО.
вместо

Таблица ПАРАМЕТРЫ
Параметер1  Параметер2 Параметер3 ...

должно быть:

Таблица ПАРАМЕТРЫ
ParameterName  ParameterValue
Параметер1       Значение Параметра 1
Параметер2       Значение Параметра 2
Параметер3       Значение Параметра 3
и т.д.

и тогда структуру таблицы менять не нужно будет. Ни часто, ни редко...



Аватар, опять ответы по сути совпали и опять Вы меня чуть-чуть опередили!!

[AnTe]

Спасибо! Но есть ещё одна проблема, - параметры могут быть разных типов, потому-то такое решение было отвергнуто. Получается, для каждого типа - свою таблицу?

[Аватар]

Не обязательно. Можно любые значения параметров хранить в VARCHAR поле. Можно иметь 2-3 разнотиповых поля, например VARCHAR, INT и NUMERIC и значение записывать в соответствующее типу параметра поле.

UPD

Надо же Второй раз в подряд в одной теме и минута в минуту

[Serge_Bliznykov]

я бы в одной таблице и держал.

либо все параметры переводил в varchar и в отдельном поле хранил тип параметра

либо, если бы с первым вариантом возникли сложности, тогда сделал так

Таблица ПАРАМЕТРЫ
ParameterName  ТипПараметра            ParamValueInt             ParameterValueChar       ParameterValueBool  и т.д. все возможные типы
Параметер1       ЗакодированныйТип    Значение Числового Параметра1 ЗначениеСтрокового Параметра1  ЗначениеЛогического Параметра1

и т.д.


добавлено

Сообщение от Аватар

Можно любые значения параметров хранить в VARCHAR поле.

не, ну это же невозможно. Коллега, вы опять на минуту меня опередили с ответом!

[AnTe]

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

Теперь у меня упрощённо три таблицы
Таблица_Детали

ID_Детали (ключевое)
Обозначение_Детали

Таблица_Параметры

ID_Параметра (ключевое)
Имя_Параметра

и главное:

Таблица_Каталог - два поля:

Counter (ключевое)
ID_детали
ID_Параметра
Значение_Параметра_int

(пусть для определённости Значение_Параметра_Char тут не будет, все параметры одного типа)

Теперь, если я правильно понимаю, работать я должен так. Например, все детали у меня имеют параметр "Длина" и "Ширина" (в перспективе возможно будут ещё параметры, но пока их нет)

Мне нужно добавить в каталог деталь "АБВГ.1234", у которой Длина = 5 Ширина = 10

Я создаю в Таблица_Параметры записи

"Length_ID"; "Длина"
"Width_ID"; "Ширина"

Я создаю в Таблица_Детали запись

"FirstDetail_ID"; "АБВГ.1234"

В Таблица_Каталог записи

"FirstDetail_ID"; "Length_ID"; 5; "5"
"FirstDetail_ID"; "Width_ID"; 10; "10"

Теперь главный вопрос - ситуацию, чтобы когда-то потом в Таблицу_Каталог не добавилось записи вроде (две длины для одной детали быть не может)

"FirstDetail_ID"; "Length_ID"; 444; "444"

должен отслеживать я сам

либо (второй вариант) Убрать в Таблица_Каталог поле Counter и сделать "FirstDetail_ID"; "Length_ID" - ключевыми

Подскажите, правильно я понял это решение?

И небольшой офф, подскажите, если возможно, какую-нибудь литературку, ссылки, попроще, покороче, для ввода в практику разработки в БД? Уровень - вот эта задача.

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

[Аватар]

либо (второй вариант) Убрать в Таблица_Каталог поле Counter и сделать "FirstDetail_ID"; "Length_ID" - ключевыми

Я бы тоже так сделал. И идентификаторы ID_Детали и ID_Параметра не делал бы символьными, а автоинкриментными типа INT

[AnTe]

Я приписал префикс "ID_" только для того, чтобы показать, что поле является идентификатором.

На самом деле как обозначение детали так и название параметра (строковые) должны быть уникальными, поэтому чтобы не делать лишних проверок, их и объявляю в качестве ключевых, автоинкремент вроде как нигде не нужен

[Аватар]

Префикс не причем. Обзывайте поле как вам удобно. Я об другом. На примере Таблица_Детали

ID_Детали (ключевое) int автоинкриментное и будет цифровым идентификатором детали. Зачем там символьное?

Обозначение_Детали varchar + можно сделать альтернативный уникальный индекс для запрета записи одинаковых наименований.

Аналогично для Таблица_Параметры

Тогда в Таблица_Каталог ID_детали и ID_Параметра будут минимальное место занимать. Да и к первым двум таблицам это имеет отношение в равной мере

И вообще предпочитаю int идентификаторы, удобнее и оптимальнее