Какую выбрать структуру базы данных для каталога с пользовательски изменяемыми полями?
Хочу разработать онлайн-каталогизатор радиодеталей, чтобы можно было вести учет, искать по параметрам, группировать, и - главное, использовать общую межпользовательскую базу данных компонентов, чтобы не расписывать каждый раз характеристики К561ЛА7, а их можно было "подтянуть" из тех, что сделали другие пользователи. А если нет, то предложить свое описание, ускорив в итоге наполнение базы...
Делаю по причине того, что все имеющиеся программы - достаточно глупые, некрасивые или просто требуют много действий...
Но в силу малого опыта работы с базами, не могу выбрать, как организовать базу.
Пока что видится мне такой вариант
1. Таблица характеристик
Поля: Группа элемента, Тип элемента, Подтип элемента, Характеристика, Тип характеристики, условное обозначение, варианты
К примеру, будет заполнено так:
- Транзисторы - Биполярные - Ток коллектора - Число - Ic
- Транзисторы - Биполярные - Напряжение коллектор-эммиттер, макс - Число - Uce
- Транзисторы - Биполярные - Структура - Список - Структура - "NPN, PNP"
2. Таблица Характеристик промодерированная
- Название элемента (PRIMARY), Группа элемента, Тип элемента, Подтип элемента, JSON-кодированная строка характеристик
Пример заполнения:
- КТ3107А, Транзисторы, Биполярные, { "Ic": 4, "Uce": "50"}
3. База пользователя
1. Название (PRIMARY), Место(а) хранения, Количество(а)
Пример заполнения
КТ3107, "ящик стола", "10"
КТ3102, "ячейка33,ячейка20", "10,0" Возможно, надо сделать иначе - на каждое место хранения - новая строка?
В итоге при добавлениии элемента
пользователь вводит название, если его не нашлось, то
выбирает группу, тип, подтип, появляется список характеристик, заполняет их, отправляет на модерацию.
Пока неотмодерировано, данная запись в базе Характеристик помечается как "Проверяется", чтобы остальные пользователи предупреждены были..
Также в характеристики должна входить возможность прикреплять графические мат-лы и док-ты, типа даташитов.. При этом для группы элементов может подходить один документ, это тоже надо как-то предусмотреть. К примеру, предлагать выбирать для элемента уже загруженные документы, ориентируясь на Группу-тип-подтип и метку, что документ содержит информацию, применимую для многих компонентов..
Насколько оптимальна такая структура?
Понятно, еще будет таблица пользователей и может еще какие-то служебные.
Также буду рад любой помощи в создании такого проекта..
документо-ориентированные базы данных вам в помощь, гуглить так же можно по запросу noSQL, если все же хочется реляционную базу данных, то смотрите EAV подход к хранению информации
а так попробуйте для начала реализовать без возможности задавать новые характеристики пользователям, неужели в радиодеталях список характеристик такой огромный и стремится к бесконечности?
Ну от не структурированых базах и EAV уже @Playbot сказал, скажу только что можно использовать готовые решения. Называются CCK. Это конструкторы котнета. Например Cobalt для Joomla.
Почему?
1. Вы получете CMS и можете так же поставить форум, галлерею, .... и быстро расширить свой сайт не затрачивая много времени.
2. Вы можете и сами кастомизировать все.
3. Экономите время на запуск проекта.
Средний
