[toweroff 0]

Добрый день

 

Даже не знаю, в какую ветку лучше запостить...

 

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

Пока планирую организовать таблицу со списком разных свойств и, соответственно, ID этих свойств

Далее будет связанная с ней таблица списка свойств товаров, в которой будет ID товара и ID свойства

 

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

 

Есть идеи, как это правильно организовать?

[CrimsonPig 0]

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

Пока планирую организовать таблицу со списком разных свойств и, соответственно, ID этих свойств

Далее будет связанная с ней таблица списка свойств товаров, в которой будет ID товара и ID свойства

 

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

Есть идеи, как это правильно организовать?

 

какой вопрос, такой ответ :)

Ставим Sqlite, делаем там таблицы и не паримся.

[toweroff 0]

какой вопрос, такой ответ :)

Ставим Sqlite, делаем там таблицы и не паримся.

ну так а я чем пользуюсь? :laughing:

 

вопрос не в СУБД как таковой, а в организации таблиц и типах данных. Как правильно организовать неизвестный заранее набор свойств с разными типами данных?

[kovigor 5]

Как правильно организовать неизвестный заранее набор свойств с разными типами данных?

Тут же рядышком есть спец. форум по программированию. Зачем пытать непрофильный форум ?

 

[CrimsonPig 0]

вопрос не в СУБД как таковой, а в организации таблиц и типах данных. Как правильно организовать неизвестный заранее набор свойств с разными типами данных?

 

Ээээ.. совсем-совсем заранее неизвестный набор ? Очень странно.

 

Обычно-то делают одну таблицу со столбцами типа Id, weight, date, ну или связанные по ключу таблицы.

 

Ну, если набор совсем неизвестен и меняется динамически, то тогда xml/json в руки, пусть у пользователей болит башка, как интерпретировать хранимые данные :)

[Ydaloj 0]

начните с техзадания.

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

Полей потребуется много, либо надо вводить чёткую систему описания. Можно триста вольт описать как 300В, 300V, 300 вольт, и под каждый вариант написания, способный прийти в голову операторам БД, надо писать свой обработчик. Проще выделить отдельный столбец с числовым значением 300, и уже никто не ошибётся.

 

да, полей много, т.к. у диода свой набор свойств, у транзистора - свой

Изменено 11 октября, 2015 пользователем Ydaloj

[toweroff 0]

В общем, скорее всего будет так:

 

Таблица1 описывает само свойство - тип данных, ширина поля и т.д.

В Таблице2 будут привязки к таблице 1 и таблице товаров. Сама таблица содержит поле BLOB (или TEXT, сейчас посмотрю, что удобнее)

В соответствии с Таблицей1 эти данные потом будут преобразовываться уже в удобоваримые типы

 

Пока лучшего не нашел

[AlexandrY 2]

В общем, скорее всего будет так:

 

Таблица1 описывает само свойство - тип данных, ширина поля и т.д.

В Таблице2 будут привязки к таблице 1 и таблице товаров. Сама таблица содержит поле BLOB (или TEXT, сейчас посмотрю, что удобнее)

В соответствии с Таблицей1 эти данные потом будут преобразовываться уже в удобоваримые типы

 

Пока лучшего не нашел

 

Чтобы решать такие вопросы надо заранее прикинуть что будете делать с этими свойствами.

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

Например нужно ли будет разбивать куски на кусочки, рулоны на метры, штуки на килограммы и т.д.

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

[toweroff 0]

Чтобы решать такие вопросы надо заранее прикинуть что будете делать с этими свойствами.

1. Товаров немного. От слова совсем немного :) наименований 500

2. Данные свойства будут использоваться как фильтр для поиска... пожалуй и все на текущий момент

 

разбивать ничего не нужно. Если это вес - то в кг, если это цвет - то число, если дата - то оно и так дата

 

короче говоря, при таком количестве записей, на скорость работы влияния окажет, считай, никакого

 

[AlexandrY 2]

1. Товаров немного. От слова совсем немного :) наименований 500

2. Данные свойства будут использоваться как фильтр для поиска... пожалуй и все на текущий момент

 

разбивать ничего не нужно. Если это вес - то в кг, если это цвет - то число, если дата - то оно и так дата

 

короче говоря, при таком количестве записей, на скорость работы влияния окажет, считай, никакого

 

Тогда бы я все свойства хранил как текст.

Но правда имеет еще значение в какой среде пишете и какие сторонние компоненты используете.

 

Бывает дальше текста и делать ничего не надо. Компонент отчетов или компонент таблицы может сам текст переводить в числа когда надо сумму показать.

В бесплатном MS SQL Express есть хорошие функции конвертации текста в любые типы на лету.

А контроль корректности ввода удобно делать триггерами в SQL движке.

 

Просто тоже имею дело с базами данных для производств.

Удобнее и дешевле MS SQL Express ничего не нашел.

[Mik174 0]

Добрый день

 

Даже не знаю, в какую ветку лучше запостить...

 

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

Пока планирую организовать таблицу со списком разных свойств и, соответственно, ID этих свойств

Далее будет связанная с ней таблица списка свойств товаров, в которой будет ID товара и ID свойства

 

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

 

Есть идеи, как это правильно организовать?

 

Если хотите все по правилам, присмотритесь к инструментам, описанным по ссылкам:

https://ru.wikipedia.org/wiki/ERwin_Data_Modeler

http://www.soljah.narod.ru/3semestr.htm

[Abell 0]

Таблица1 описывает само свойство - тип данных, ширина поля и т.д.

В Таблице2 будут привязки к таблице 1 и таблице товаров. Сама таблица содержит поле BLOB (или TEXT, сейчас посмотрю, что удобнее)

В соответствии с Таблицей1 эти данные потом будут преобразовываться уже в удобоваримые типы

Пока лучшего не нашел

Вот у Вас есть товар, есть набор разных свойств, и к одному товару применяется один список свойств, к другому - иной, правильно понял?

То есть, нужны промежуточные таблицы - типы и свойства товара, и сводная таблица.

 

Например, есть тип товара:

1-резистор, 2-конденсатор, 3-дроссель, 4-биполярный транзистор

 

Есть свойства:

1-сопротивление, 2-емкость, 3-индуктивность, 4-h21e, 5-дата выпуска

 

Есть сводная таблица (тип/свойства):

1/1, 1/5, 2/2, 2/5, 3/3, 3/5 и т.д.

 

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

В базах SQL вроде бы примерно так права доступа реализуются :)

 

Запросы, конечно, будут намного сложнее, как и формы ввода, и отчеты :laughing:

 

Лет 15 назад, в проекте "DataExplorer", решались подобные задачи, да так и не решились полностью - гензаказчик внедрил 1с и доволен :laughing:

[Abell 0]

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

Разные таблицы :laughing:

[AndryG 0]

1. Товаров немного. От слова совсем немного sm.gif наименований 500

2. Данные свойства будут использоваться как фильтр для поиска... пожалуй и все на текущий момент

Не убивайте себе будущее )

Сделайте одну таблицу с кучей полей. И используйте только те, что надо в каждом конкретном типе записи. Да будут "пустые места". но зато просто, дубово и надежно.

 

Если очень жалко места или БД вырастет до гигов, то доп поля вынести в отдельные таблицы "доп. поля транзисторов" "доп поля резисторов".

 

Не извращайтесь с вариантом "справочник типов значений" "справочник типов полей" "справочник доп. полей" "значения доп. полей" - SQL не любит работать с такими данными. Заимеете проблем на голову. И чем дальше - тем больше.