Структура таблицы Базы Данных

[poweroff]

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

Необходимо создать таблицу, в которой будут учтены все комплектующие товара, такие как отвёртка, диоды, канифоль и т. д..
Можно под каждую составляющею создать поле:

Пример №1

Поле «отвёртка», и число обозначающее их количество. Но если в комплекте товара входит две разных отвёртки (крестовая, плоская) то под каждую надо создавать своё поле, что не желательно, ведь у других товаров крестовых отвёрток может не быть совсем, и следовательно это поле будет всегда пустым в них. А в некоторых товаров вообще нету отвёрток.

Пример №2

Если в комплекте 20 светодиодов, и они разного цвета и мощности. Придётся делать три поля: цвет, мощность и количество.

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

За ранее спасибо.

[grAndrew2]

Есть 2 способа рационализации:

самый прямой - использовать в таком случае объектную базу данных, например, db4o, zodb или адаптированный postgresql orm.

Второй - самый популярный - использовать ORM (object-relational mapping) - Есть множество проектов, подо все типы реляционных баз. Там же есть и описание, как правильно сконфигурировать таблицы, как задачать запросы и т.п. - см, например, http://lmgtfy.com/?q=orm+mysql

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

И все же я рекомендовал бы поизучать объекнтые БД.

[Warlornhor]

Я бы создал несколько таблиц: отвертка, диод... Там поля которые относятся Только к определенному типу оборудования.

[poweroff]

grAndrew2 Спасибо, открыл для себя много новых слов. Про объектные БД пожалуй почитаю литературку, кстати, а не посоветуете что нибуть на русском из этого.

Warlornhor Именно так я изначально и сделал, но смущает то, что если в комплекте 7 видов диодов, то надо семь полей, а в другом комплекте их может быть лишь один. Выходит что 6 полей пустуют, именно это мне и не нравится.

[sciko]

ИМХО, пример 1 -- это классическая задача связать две таблицы по схеме "многие к многим".

Таблица 1: id|Количество|Отвёртка
Таблица 2: id|Тип (Тип -- это крестообразная или плоская)
Таблица 3: id|id таблицы 1|id таблицы 2

В общем получается таблица с большим количеством полей, которые могут быть и не заполненными.

Это как? Второй пример не понял.

[poweroff]

В общем получается таблица с большим количеством полей, которые могут быть и не заполненными.

Это как? Второй пример не понял.

Имеется в виду, что некоторые поля будут пустыми(не заполненными), потому что у некоторых товаров будут просто отсутствовать данные элементы (например не будет зелёных диодов).
Точнее они будут заполнены нулями, а мне не хотелось бы тратить поля таблицы, на значения которых не будет.

[grAndrew2]

grAndrew2 Спасибо, открыл для себя много новых слов. Про объектные БД пожалуй почитаю литературку, кстати, а не посоветуете что нибуть на русском из этого.

литературы на русском, к сожалению, не знаю. Можете начать с википедии.

ИМХО, пример 1 -- это классическая задача связать две таблицы по схеме "многие к многим".

Таблица 1: id|Количество|Отвёртка
Таблица 2: id|Тип (Тип -- это крестообразная или плоская)
Таблица 3: id|id таблицы 1|id таблицы 2

В общем случае описанный sciko пример называется ORM

[poweroff]

grAndrew2 Вики уже прочёл, спасибо.

В примере который показал sciko, на сколько я понял, нельзя реализовать вариант: 2 крестовых отвёртки и одна плоская. А можно только одна или несколько крестовых или плоских отвёрток.

[grAndrew2]

grAndrew2 Вики уже прочёл, спасибо.

В примере который показал sciko, на сколько я понял, нельзя реализовать вариант: 2 крестовых отвёртки и одна плоская. А можно только одна или несколько крестовых или плоских отвёрток.

можно -
Отвертка - Крестовая - 2
Отвертка - Плоская - 1
для отработки необходимо использовать операцию JOIN по полям id и выборку по типу и наименованию товара

[Crazy]

Есть такой фундаментальный труд
Введение в системы баз данных. К. Дж. Дейт, в котором изложены разные методы проектирования БД.

[Portnov]

grAndrew2
Никакое это не ORM, объектами не пахнет. Это просто связь "многие-ко-многим".

poweroff
А какую информацию нужно хранить об этих отвёртках, канифоли и прочей канители? Если только наличие - то, вероятно, не нужно ни таблиц, ни полей, можно всё в одном поле хранить (например, в виде битовой маски). Если много полей - то как-то так:

Таблица Товары: id, остальные поля
Таблица Отвёртки: id, id_товара, номер_отвёртки_в_комплекте, остальные поля

ну и т.д.

[grAndrew2]

grAndrew2
Никакое это не ORM, объектами не пахнет. Это просто связь "многие-ко-многим".

Как видите, я не настаиваю на применении ORM, я просто настоятельно рекомендую ;-) . Это позволит человеку расти и смело войти в современный мир. Задача прекрасно подходит для ORM-движков, а товар со множеством связей по различным парметрам - прекрсно описывается объектом с соответствующими свойствами.

[Crazy]

В общем случае описанный sciko пример называется ORM

Обычное правило правило преобразования связи "многие ко многим", применяющаяся в таких методах как ER-метод, при переходе с логического уровня на физический.

[Warlornhor]

Warlornhor Именно так я изначально и сделал, но смущает то, что если в комплекте 7 видов диодов, то надо семь полей, а в другом комплекте их может быть лишь один. Выходит что 6 полей пустуют, именно это мне и не нравится.

Для 7-ми видов диодов нужно 7 Строк, а не полей, для еще одного еще одна строка и так далее. Например:
Диоды:
_________________
|ID|Type|Color|Smt|

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

[Wagan]

А может стоит 1С попробовать, они грозятся, что на Линуксе все ок, и Склад там по-взрослому сделан. Или это грустная затея? Сам не пробовал, просто интересен опыт работы существующих БД, а не самодельных.

[begin2009]

А может стоит 1С попробовать, они грозятся, что на Линуксе все ок, и Склад там по-взрослому сделан. Или это грустная затея? Сам не пробовал, просто интересен опыт работы существующих БД, а не самодельных.

Боюсь соврать, но вроде там только клиент. А сервер должен быть на офтопике.

[IMB]

Боюсь соврать, но вроде там только клиент. А сервер должен быть на офтопике.

Всё с точность наоборот. С клиентом как раз грустно, а сервер можно.

[Wagan]

Автора темы наверное интересуют оба варианта, и сервера и клиента. А я скажу спасибо за инфо, вернее за наводку, мне как раз нужно сервер поднимать, причем не на РС, а на железке с АРМом, поэтому хотелось воспользоваться чем-то готовым.

[IMB]

Автора темы наверное интересуют оба варианта, и сервера и клиента. А я скажу спасибо за инфо, вернее за наводку, мне как раз нужно сервер поднимать, причем не на РС, а на железке с АРМом, поэтому хотелось воспользоваться чем-то готовым.

http://packages.debian.org/lenny/armel/mys...er-5.0/filelist
http://packages.debian.org/lenny/armel/sqlite/filelist
Подойдёт?
Ну а если серьёзно коллега, позволю себе такое обращение по причине того, что сам сейчас работаю с ARM, то Вы зашли немного нестого бока. Я бы отталкивался от имеющихся мощностей и требуемого фукционала. Ведь никто не мешает собрать PostgreSQL под ARM, но вот потянет ли железо?

[Wagan]

IMB, согласен на любое обращение))) но, думаю, это обсуждение лучше перевести в специально созданную ранее тему. Там как раз можно обсудить обоюдоинтересные вопросы, раз Вас привлекает АРМ.