Jump to content

    
Sign in to follow this  
toweroff

База данных - свойства товара

Recommended Posts

Добрый день

 

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

 

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

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

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

 

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

 

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

Share this post


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

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites
какой вопрос, такой ответ :)

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

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

 

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

Share this post


Link to post
Share on other sites
Как правильно организовать неизвестный заранее набор свойств с разными типами данных?

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

 

Share this post


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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Edited by Ydaloj

Share this post


Link to post
Share on other sites

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

 

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

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

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

 

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

Share this post


Link to post
Share on other sites
В общем, скорее всего будет так:

 

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

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

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

 

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

 

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

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

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

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

Share this post


Link to post
Share on other sites
Чтобы решать такие вопросы надо заранее прикинуть что будете делать с этими свойствами.

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

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

 

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

 

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

 

Share this post


Link to post
Share on other sites
1. Товаров немного. От слова совсем немного :) наименований 500

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

 

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

 

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

 

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

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

 

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
Добрый день

 

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

 

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

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

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

 

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

 

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

 

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

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

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

Share this post


Link to post
Share on other sites
Таблица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:

Share this post


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

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

Share this post


Link to post
Share on other sites
1. Товаров немного. От слова совсем немного sm.gif наименований 500

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this