Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / структура таблиц при неизвестном количестве параметров / 25 сообщений из 43, страница 1 из 2
26.06.2013, 14:01
    #38311238
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Доброго дня всем.
Подскажите, пожалуйста, какой способ реализации более оптимален?
Есть База данных по оборудованию, в ней есть Библиотека оборудования. Для каждой номенклатуры есть свои технические характеристики. Условно, эти технические характеристики могут быть только нескольких типов, например: int, nvarchar(100), datetime, numeric(12,4) и varbinary(max). Но в каждой номенклатуре может быть неопределенное количество этих технических характеристик с наименованием этой характеристики.
1-й вариант. В таблице ListOfDatasheetParameter хранить список параметров, а потом на основании этой таблицы формировать XML, и сами характеристики сохранять в EquipmentsDatasheetsXML, а связанные с этой номенклатурой файлы хранить уже в EquipmentsDatasheetsOLE.
2-й вариант - это иметь для каждого типа данных свою таблицу с именем и значением характеристики.

Модератор: Тема перенесена из форума "Microsoft SQL Server".
...
Рейтинг: 0 / 0
26.06.2013, 14:03
    #38311240
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
файл почему-то не прикрепился
...
Рейтинг: 0 / 0
26.06.2013, 14:25
    #38311284
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Если по характеристикам нужен поиск, то - EAV практически без вариантов.
Если достаточно их просто показывать - любой формат, удобный для показа в BLOB поле.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
26.06.2013, 14:30
    #38311294
Сергей Викт.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Лина1995Доброго дня всем.
Подскажите, пожалуйста, какой способ реализации более оптимален?
Есть База данных по оборудованию, в ней есть Библиотека оборудования. Для каждой номенклатуры есть свои технические характеристики. Условно, эти технические характеристики могут быть только нескольких типов, например: int, nvarchar(100), datetime, numeric(12,4) и varbinary(max). Но в каждой номенклатуре может быть неопределенное количество этих технических характеристик с наименованием этой характеристики.
1-й вариант. В таблице ListOfDatasheetParameter хранить список параметров, а потом на основании этой таблицы формировать XML, и сами характеристики сохранять в EquipmentsDatasheetsXML, а связанные с этой номенклатурой файлы хранить уже в EquipmentsDatasheetsOLE.
2-й вариант - это иметь для каждого типа данных свою таблицу с именем и значением характеристики.

Модератор: Тема перенесена из форума "Microsoft SQL Server".

1й вариант.Второй вариант в плане поддержки будет неудобен.
...
Рейтинг: 0 / 0
26.06.2013, 15:48
    #38311467
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Тему зачем-то перенесли из MS SQL'я... Ну да не суть, как важно
Тогда добавлю, что СУБД MS SQL 2005
Поиск по характеристикам будет и это будет выборка по "типу оборудования"+"название характеристики", либо "наименование оборудования"+"название характеристики".
Поиск по XML документу - это сложно и/или долго?
...
Рейтинг: 0 / 0
26.06.2013, 21:45
    #38311933
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Лина1995Подскажите, пожалуйста, какой способ реализации более оптимален?2-й вариант, то есть EAV с разделением на таблицы по типам.
Первый вариант будет неудобен в плане поддержки.
...
Рейтинг: 0 / 0
26.06.2013, 22:15
    #38311949
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
> какой способ реализации более оптимален?

Если вы сформулируете критерий оптимальности, будет шанс получить ответ. Оба приведенных вами варианта безобразно кривы.

Судя по всему, у мелкомягких юзеров раздел "проектирование" не в почете, однако, если вы воспользуетесь поиском, то легко найдете ключевые обсуждения задач, подобных вашей.
...
Рейтинг: 0 / 0
27.06.2013, 07:09
    #38312068
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Ну а все таки, вариант 1-й и поиск с like '%bla-bla-bla%' в XML полях - это сильные тормоза?
при условии, что планируется до 100-150тыс записей
...
Рейтинг: 0 / 0
27.06.2013, 07:11
    #38312069
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
guest_20040621> какой способ реализации более оптимален?

Если вы сформулируете критерий оптимальности, будет шанс получить ответ. Оба приведенных вами варианта безобразно кривы.

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

Если не сложно, то укажите варианты, дайте сслылки, пожалуйста
...
Рейтинг: 0 / 0
27.06.2013, 08:23
    #38312088
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Лина1995Ну а все таки, вариант 1-й и поиск с like '%bla-bla-bla%' в XML полях - это сильные тормоза?
при условии, что планируется до 100-150тыс записейСильные. Вообще говоря, в XML полях в MSSQL есть даже индексированный поиск.
Но даже в этом случае будет медленее, чем с таблицами.
...
Рейтинг: 0 / 0
27.06.2013, 10:04
    #38312180
LSV
LSV
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Лина1995Если не сложно, то укажите варианты, дайте сслылки, пожалуйстаА зачем ? Они тоже будут безобразно кривы. :)

Не парьтесь. EAV реализуется за пару дней и легко прикручивается к любой готовой (в т.ч. сторонней) системе. :)
...
Рейтинг: 0 / 0
27.06.2013, 13:19
    #38312516
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
> Если не сложно

Не сложно. Сформулируйте критерий оптимальности. За что вы боретесь?

Формулировка "неизвестное количество параметров" недостаточна. Давайте начнем с того, что мы можем классифицировать все параметры, т. е. что-то мы о них знаем. Обычно вопрос, подобный вашему, привлекает кучу дегенеративных советчиков, которые начинают рассказывать про EAV. Вы должны понимать, что EAV - временный коллектор, никакой другой нагрузки у него нет. Предлагаю вам немного по-другому посмотреть на вашу задачу. Для большого количества характеристик есть общепринятые шкалы. Хороший пример - энергопотребление. Можно выделить группу характеристик, связанных с коммутацией (физическая, электрическая и пр. совместимость), имеющих стандартные наименования и обозначения. Можно выделить группу характеристик, связанных с архитектурой - условно - устройств. Если вы таким образом начнете группировать характеристики, ваша задача немного изменится.
...
Рейтинг: 0 / 0
27.06.2013, 13:39
    #38312551
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
guest_20040621> Если не сложно

Не сложно. Сформулируйте критерий оптимальности. За что вы боретесь?

Формулировка "неизвестное количество параметров" недостаточна. Давайте начнем с того, что мы можем классифицировать все параметры, т. е. что-то мы о них знаем. Обычно вопрос, подобный вашему, привлекает кучу дегенеративных советчиков, которые начинают рассказывать про EAV. Вы должны понимать, что EAV - временный коллектор, никакой другой нагрузки у него нет. Предлагаю вам немного по-другому посмотреть на вашу задачу. Для большого количества характеристик есть общепринятые шкалы. Хороший пример - энергопотребление. Можно выделить группу характеристик, связанных с коммутацией (физическая, электрическая и пр. совместимость), имеющих стандартные наименования и обозначения. Можно выделить группу характеристик, связанных с архитектурой - условно - устройств. Если вы таким образом начнете группировать характеристики, ваша задача немного изменится.
По сути это часть БД, и это в этой части: Библиотека оборудования используемого на предприятии. Это все оборудование: механическое, электрическое, энергетическое и т.д., у каждой единицы оборудования свои технических характеристики, а кроме этого эти характеристики могут со временем расширяться (дополняться). Например, электродвигатель - это: напряжения, токи, обороты, габаритные размеры и т.п., болты - это размеры, тип резьбы, материал изготовления...
Варианты с древовидным делением типов оборудования не предлагать, так как руководство такой вариант сразу отвергло.
...
Рейтинг: 0 / 0
27.06.2013, 13:50
    #38312577
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
guest_20040621> Если не сложно

Не сложно. Сформулируйте критерий оптимальности. За что вы боретесь?


Если честно, то сформулировать за что борюсь, пока не совсем могу, так как сама не до конца понимаю.
Раз это библиотека, то она должна быть удобной и функциональной. Должна быть возможность легко добавлять новые технические параметры, если нужно. Кроме того необходимо обеспечивать быстрый поиск по наименованию оборудования, а также по каким-то техническим характеристикам. Например, выбрать электродвигатели с оборотами 1200об/мин и номинальной мощностью 10кВт.
Что-то типа select * from biblioteka b join harakteristiki h on b.id=h.fid where b.name like '%элетродвигатель%' and h.name_param like '%обороты%' and h.param_value = 1200 и т.д. (конечно запрос некорректный), но что-то в этом виде.
Как то же самое сделать иначе, я пока не представляю.
...
Рейтинг: 0 / 0
27.06.2013, 14:17
    #38312632
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Лина1995guest_20040621> Если не сложно

Не сложно. Сформулируйте критерий оптимальности. За что вы боретесь?


Если честно, то сформулировать за что борюсь, пока не совсем могу, так как сама не до конца понимаю.
Раз это библиотека, то она должна быть удобной и функциональной. Должна быть возможность легко добавлять новые технические параметры, если нужно. Кроме того необходимо обеспечивать быстрый поиск по наименованию оборудования, а также по каким-то техническим характеристикам. Например, выбрать электродвигатели с оборотами 1200об/мин и номинальной мощностью 10кВт.
Что-то типа select * from biblioteka b join harakteristiki h on b.id=h.fid where b.name like '%элетродвигатель%' and h.name_param like '%обороты%' and h.param_value = 1200 и т.д. (конечно запрос некорректный), но что-то в этом виде.
Как то же самое сделать иначе, я пока не представляю.
Cлово "функциональный" в Вашем описании не очень информативно. у EAV (и у варианта с XML, кстати, тоже) -проблемы со сложными бизнес-функциями над обьектами. Если Вам ничего сложнее поиска и показа характеристик от системы не нужно - EAV
б.м. справится. А вот если Вам с обьектами и их характеристиками нужно делать много всего (всякие там принятия на склад, списания со склада, перерасчет себестоимости, etc.) - это уже хуже.
...
Рейтинг: 0 / 0
27.06.2013, 14:17
    #38312635
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Лина1995поиск с like '%bla-bla-bla%' в XML полях - это сильные тормоза?

Такой like это сильные тормоза при любом раскладе. Только в XML это ещё может и не
сработать из-за внутреннего кодирования.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2013, 14:23
    #38312659
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Кот Матроскин Cлово "функциональный" в Вашем описании не очень информативно. у EAV (и у варианта с XML, кстати, тоже) -проблемы со сложными бизнес-функциями над обьектами. Если Вам ничего сложнее поиска и показа характеристик от системы не нужно - EAV
б.м. справится. А вот если Вам с обьектами и их характеристиками нужно делать много всего (всякие там принятия на склад, списания со склада, перерасчет себестоимости, etc.) - это уже хуже.
Эта часть - это библиотека. Всякие там принятия на склад - это другая часть, а здесь ТОЛЬКО библиотека из которой уже формируется перечень со всеми своими привязками.
Мне так самой проще было бы с XML, но так как там тормоза с поиском будут, то это уже не подходит.
...
Рейтинг: 0 / 0
27.06.2013, 14:30
    #38312674
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
> у каждой единицы оборудования свои технических характеристики

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

> габаритные размеры и т.п., болты - это размеры, тип резьбы, материал изготовления...

Вы сами уточняете задачу. Габаритные размеры - понятно. Электродвигатель - стационарное устройство, способ установки - винтовое соединение, жёстко закрепленная в основании шпилька (характеристики). И таким образом крепиться будут не только электродвигатели.

> Раз это библиотека, то она должна быть удобной и функциональной.

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

> быстрый поиск по наименованию оборудования, а также по каким-то техническим характеристикам

Это простая часть. Imho наиболее сложно в данном случае выбрать правильный уровень абстракции и использовать корректные характеристики. Не двигатель вращается, а вал двигателя. ;) Следующая проблема - выбор идентифицирующего наименования. Пользователь может видеть "электродвигатель", но в базе данных он может быть сопоставлен другой конструкции.

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

P.S. Трудовые отношения вас и вашего работодателя - не мое дело, конечно, но я бы попросил за решение такой задачи серьезное количество бабла. Насколько я могу об этом судить, решений промышленного качества не существует.
...
Рейтинг: 0 / 0
27.06.2013, 14:38
    #38312693
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Лина1995Кот Матроскин Cлово "функциональный" в Вашем описании не очень информативно. у EAV (и у варианта с XML, кстати, тоже) -проблемы со сложными бизнес-функциями над обьектами. Если Вам ничего сложнее поиска и показа характеристик от системы не нужно - EAV
б.м. справится. А вот если Вам с обьектами и их характеристиками нужно делать много всего (всякие там принятия на склад, списания со склада, перерасчет себестоимости, etc.) - это уже хуже.
Эта часть - это библиотека. Всякие там принятия на склад - это другая часть, а здесь ТОЛЬКО библиотека из которой уже формируется перечень со всеми своими привязками.
Мне так самой проще было бы с XML, но так как там тормоза с поиском будут, то это уже не подходит.

Я делал на EAV хранилище [разнородных] обьектов из разных систем - т.е. практически Ваша задача. Сделано было быстро, работало достаточно шустро.
Вариант с хранением XML тоже я бы не хоронил сразу (хотя мне лично удобнее "чистый" EAV) - сделайте стенд, нагенерите N обьектов и померяйте. Может, эти "тормоза" будут вполне в рамках допустимого.
Только обязательно используйте не LIKE, а встроенный тип xml и его операции поиска - в SQL Server он довольно мощный.
...
Рейтинг: 0 / 0
27.06.2013, 14:51
    #38312721
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Кот МатроскинЯ делал на EAV хранилище [разнородных] обьектов из разных систем - т.е. практически Ваша задача. Сделано было быстро, работало достаточно шустро.
Вариант с хранением XML тоже я бы не хоронил сразу (хотя мне лично удобнее "чистый" EAV) - сделайте стенд, нагенерите N обьектов и померяйте. Может, эти "тормоза" будут вполне в рамках допустимого.
Только обязательно используйте не LIKE, а встроенный тип xml и его операции поиска - в SQL Server он довольно мощный.

Спасибо, наверное, именно так и попробую. Разрабатывать что-то слишком серьезное - у меня нет опыта и достаточных знаний, а уж требовать серьезную оплату, то тут даже никто и говорить не будет... :)
Вопрос возник потому, что у нас сейчас решается вопрос о внедрении sap pm, но все хотят хоть три копейки с'экономить, вот и получается всякая ерунда.
...
Рейтинг: 0 / 0
27.06.2013, 15:11
    #38312766
vadiminfo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Лина1995Вопрос возник потому, что у нас сейчас решается вопрос о внедрении sap pm, но все хотят хоть три копейки с'экономить, вот и получается всякая ерунда.
Т.е. внедряют sap pm, и тут же разрабатыват свое поделие? Плиз, уточните чем же экономия?
...
Рейтинг: 0 / 0
27.06.2013, 16:24
    #38312935
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
> именно так и попробую

Это не решение, это костыли. Хозяин - барин, конечно, но на вашем месте я бы попробовал поэкспериментировать.
...
Рейтинг: 0 / 0
27.06.2013, 18:47
    #38313221
SERG1257
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Поддержу guest_20040621, использовать EAV для вас означает "замазать" проблему, перенести ее на потом.
То бишь неизвестном количестве параметров следует читать неизвестном для вас.
Не рискну давать советы (что лучше стартовать сейчас с синицей в руках или день потерять, а потом за пять минут долететь) в вашем случае, замечу, что проблема всех таких паллиативов в том, что в случае УСПЕШНОЙ реализации (большая нагрузка, множество пользователей) чтобы расшить узкие места создается почти параллельная нормальная структура из зависимых полей таблиц или даже баз. Все неизвестные параметры становятся известными, а для того чтобы согнуть такую "гибкую" архитектуру приходится все равно применять наркоз, причем по причинам далеким от структуры базы.
...
Рейтинг: 0 / 0
27.06.2013, 21:14
    #38313322
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
vadiminfoЛина1995Вопрос возник потому, что у нас сейчас решается вопрос о внедрении sap pm, но все хотят хоть три копейки с'экономить, вот и получается всякая ерунда.
Т.е. внедряют sap pm, и тут же разрабатыват свое поделие? Плиз, уточните чем же экономия?
В эту большую политику больших начальников я не лезу, да и меня там точно никто не послушает. Скажут копать, будем копать...
Я рада, если у вас иначе, но у нас вот так вот :-\
...
Рейтинг: 0 / 0
27.06.2013, 21:31
    #38313335
Лина1995
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц при неизвестном количестве параметров
Ребята, я честное слово рада была бы сделать КАК НАДО и КАК ЛУЧШЕ. Но моих знаний на сегодняшний день крайне мало, чтобы что-то серьезное сделать, а результаты нужны супер-пупер быстро :-(
Объяснить руководству, которое считает, что IT это что-то типа "нажал одну кнопочку, ну максимум две и тут же тебе все на тарелочке с золотой каёмочкой", а вдобавок это менеджера, которые в итоге за конечный результат не отвечают... вот и делайте выводы.
Ну а по задаче, то на самом деле получается, что заранее список всех технических параметров никто не скажет, сказано, что они будут частично внесены вначале, а потом будут довноситься, причем в любой момент нужно расширять. В общем не типы данных ни их количество естественно неизвестно, но я думаю, что для такой задачи это нормально.
В общем-то предполагается не более 20-25тыс номенклатур оборудования и материалов. Соответственно, если делать через XML, то и там получится не более 25тыс записей. Возможно, что при таком количестве скорость поиска будет терпимой. Но завтра попробую поэксперементировать. Только возник вопрос, а как лучше сделать тестовые данные? Я подумала так: накидать порядка 100тыс одинаковых данных XML, и докинуть порядка 100-200 тех, которые мне как бы нужны, и посмотреть время выборки, ну хотя бы от 10 клиентов.
К XML возвращаюсь, так как и программисты, которые будут писать пользовательские формы, тоже очень просили именно за вариант с XML'ем. И если только результаты теста будут неприемлемы, то буду делать через EAV
Но если кто предложит другую рабочую структуру, то с удовольствием попробую ее реализовать.
Большое спасибо всем, кто отозвался!
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / структура таблиц при неизвестном количестве параметров / 25 сообщений из 43, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]