Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Необходимо сконструировать базу деталей. Разновидностей деталей около 50, т.е. болты, трафареты и т.д. Разумеется, они имеют разное количество характеристик. Хотелось-бы услышать Ваше мнение по поводу того, что является более рацональным решением - создать 50 таблиц (по таблице на каждый вид), или создать одну таблицу, запихать в нее все возможные характеристики, а в неиспользуемых полях для конкретного типа использовать null. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 11:52 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> что является более рацональным решением Рациональным с какой точки зрения? Одна таблица - проще и быстрее. 50 - сложнее и дольше. Третий вариант: таблица деталей, перечень характеристик, таблица характеристик деталей. Можно добавить констрейнт таблицу (каким деталям какие характеристики соответствуют), если можно выделить группы деталей, например. Можно добавить классификатор и типы характеристик. Нужна КД? Тоже таблица + таблица соответствия. Нужны единицы измерения? Таблица единиц измерений. Нужен пересчет из одних величин в другие? - таблица приведения. Есть сборочные узлы в готовых изделях? Таблица комплектности. Нужна история изменений (характеристик или КД)? ;) В таком примерно ключе. ;) Хотя, конечно, можно и одной таблицей обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 14:29 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
что-то не совсем понятно по-поводу третьего варианта, в чем собственно смысл переноса характеристик в отдельную таблицу ? Определенные характеристики детали (ширина например) там все равно не будут заполнены, в итоге принципиальной разницы с первым вариантом нет, зато появятся дополнительные тормоза. Или Вы имели в виду создание таблицы для каждой характеристики ? (т.е. таблица длин, таблица диаметров и т.д.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 16:24 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Скорее он имел в виду то, что будет справочник характеристик, а также таблица со значениями характеристик, связанная также со справочником деталей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 17:09 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Это как раз тот плохой случай для реляционной модели. Одна таблица - ухудшение качества отображения информации за счет "искажения" структуры: то что выглядит атрибутами для одного вида деталей - превратилось в значения. А поскольку система запросов строится на использовании атрибутов соответствующие "преобразования запросов". Извлечение информации усложнится. Здесь еще и то, что некоторые характеристики числовые, а некоторые символьные. Теперь все символьные. Вообще ограничения целостноти на значения накладывать сложнее. Однако, если все эти недостатки в данной задаче не могут сильно проявиться, то, наверное, решение - одна таблица, может иметь смысл. Обычно это имеет смысл, когда сама информация о характеристиках этих деталей не так важна. 50 таблиц - одна на вид детали - большое число таблиц в общем-то для очень схожих типов сущностей - видов деталей, которык к тому же выглядят как сущности - т.е. возможно появление нового вида деталей. Похоже здесь обратная ситуация то, что похоже на кортеж превращается в отношение. Если в одном запросе про все виды детадлей - 50 таблиц в запросе. А если появится 51, 52 и т.д. - вид деталей? Добавление новых таблиц - измение структуры - новая версия БД, и скорее всего приложения. Структура на то и структура, чтобы быть относительно статичной частью системы (ведь те же запросы еще придется переписывать, где участвуют детали всех видов). В общем это решение тоже плоховато. Конечно, если эти недостатки для конкретной задачи имеют значение. Решения с изменяющейся структурой - не самым лучшим образом согласуются с идеей статичности понятия структуры, т.е. объективно должно ухудшиться то, для чего это понятие существует. Думаю, что стоит подумать об объектных возможностях современных ОРСУБД. Тогда то, что здесь предлагали решить изменчивостью реляционной структуры, можно попробовать - решить с помощью пользовательских типов объетов, а то что реляционным методом так и оставить. Т.е. нивилировать эти недостаки используя преимущества двух этих технологий. Сейчас большинство лидирующих СУБД поддерживают такую возможность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 22:28 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> в чем собственно смысл переноса характеристик в отдельную таблицу ? 1. Удобно их (характеристики) администрировать. 2. Абсолютно нежесткая структура. 3. Удобно пользоваться разными стандартами при описании (децимальная/двоичная система счисления и пр.). > принципиальной разницы с первым вариантом нет, Именно принципиальная. > Или Вы имели в виду создание таблицы для каждой характеристики? Нет. Есть смысл разделить характеристики на числовые, символьные и перечисляемые и при описании указывать их тип. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2004, 09:49 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
vadiminfoЭто как раз тот плохой случай для реляционной модели. ...Думаю, что стоит подумать об объектных возможностях современных ОРСУБД. Тогда то, что здесь предлагали решить изменчивостью реляционной структуры, можно попробовать - решить с помощью пользовательских типов объетов, а то что реляционным методом так и оставить. Т.е. нивилировать эти недостаки используя преимущества двух этих технологий. Сейчас большинство лидирующих СУБД поддерживают такую возможность. А то что Вы предлагаете не плохой способ для реляционной модели? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 10:15 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
StalkerS, юзай отношение подкатегории в полный рост. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 11:05 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
StalkerS, юзай предложенный в треде подход "База данных-хранилище атрибутов объектов" только в случае, если есть требование добавления новых сущностей ПОСЛЕ внедрения БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 11:08 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
StalkerSРазновидностей деталей около 50, т.е. болты, трафареты и т.д. Разумеется, они имеют разное количество характеристик. Не дурно бы разобраться - а нужно ли учитывать все эти характеристики? Как правило, в машиностроении для работы хватает габаритных размеров, материала, собственно типа детали и ГОСТа. Ну и правильное название ессно. Все остальное - вторично и носит характер примечания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 11:11 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Как правило, в машиностроении для работы хватает габаритных размеров, > материала, собственно типа детали и ГОСТа. Хм... Member Серега поделится своим видением проблемы относительно материалов и типов? > Все остальное - вторично и носит характер примечания. Другими словами, Вы думаете, что достаточно их просто через запятую перечислить? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 13:16 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Хм... Member Серега поделится своим видением проблемы относительно материалов и типов? А что конкретно интересует в этом вопросе, Guest guest_20040621? Это вообще проблема? guest_20040621Другими словами, Вы думаете, что достаточно их просто через запятую перечислить? ;) А как больше ндравится. Можно и через дефис. 8-) А что достаточно для данной задачи я не знаю. Сведения о задаче крайне скудны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 16:26 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> А что конкретно интересует в этом вопросе? Структура данных, разумеется. > Это вообще проблема? Не совсем. Скажем так: нетривиальная задача. > А как больше ндравится. Можно и через дефис. 8-) А можно через какой-нибудь юникодовый иероглиф? Прикольнее, чем дефис и запятая вместе взятые. > А что достаточно для данной задачи я не знаю. Сведения о задаче крайне скудны. Любопытно, какие еще данные требуются для ее детализации, которые принципиально повлияли бы на структуру данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 18:55 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Dik76 А то что Вы предлагаете не плохой способ для реляционной модели? На самом деле, я скорее не предложил, а обратил внимание на возможность рассмотреть подход на основе объектно-реляционной модели данных. Все-таки чтобы оставаться только в реляционной модели для данного приложения приходится идти на ухищрения при моделировании, последствия которых на протяжении всего жизненного цикла информационной системы не до конца ясны. Безусловно и ОР подход означает и усложнение запросов, возможно и ОРСУБД еще не совсем достаточно поддерживают объектную составляющую для решения реальных задач. Плюс багов наверное там хватает. Наверное усложнится и программирование. Но плюсом может быть и более адекватное моделирование (тоже пока лишь предположение). И, например, запросы усложнятся только немного в плане синтаксиса, но не в плане компенации ухищрений моделирования. Последнее в общем случае на этапе эксплуатации ИС может оказаться для нее критичным - отрицательно сказаться на продолжительности жизненного цикла. Но речь идет только о том, чтобы если есть возможность, проверить и этот подход. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 20:33 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Структура данных, разумеется. А что структура? Обычная структура. Справочники (id,name) и ссылка на них в "главной" таблице. Справочники могут быть и с деревянной "структурой" если интересует более детальный анализ. guest_20040621Не совсем. Скажем так: нетривиальная задача. Да ну? ИМХО обычная. Главное не перестараться. 8-) Надо определиться "скока точно вешать в граммах". Иными словами - если не нужен анализ/статистика по количеству разных отверстий в детали, то нефига и параметр хранения такой плодить. Достаточно, если уж сильно хочется, через запятую (дефис, иероглиф). guest_20040621Любопытно, какие еще данные требуются для ее детализации, которые принципиально повлияли бы на структуру данных? Для решения этой задачи, неплохо бы было описать те самые "характеристики", которые разные и которых много. А так же за чем они нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 09:05 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621 > А что достаточно для данной задачи я не знаю. Сведения о задаче крайне скудны. Любопытно, какие еще данные требуются для ее детализации, которые принципиально повлияли бы на структуру данных? Например, какие характеристики будут участвовать в выборках, по каким будут строится отчеты. Хотя, если даже удастся выделить характеристики, которые можно отнести к примечаниям, то оставшаяся их часть не обязательно будет совпадать по структуре. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 09:07 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
vadiminfo Dik76 А то что Вы предлагаете не плохой способ для реляционной модели? На самом деле, я скорее не предложил, а обратил внимание на возможность рассмотреть подход на основе объектно-реляционной модели данных. Хотелось бы узнать у автора топика, какую СУБД он собирается использовать? Все-таки чтобы оставаться только в реляционной модели для данного приложения приходится идти на ухищрения при моделировании, последствия которых на протяжении всего жизненного цикла информационной системы не до конца ясны. Предложенное решение в посте 1003997 предполагает использование в рамках реляционной модели, усеченное описание детали в виде объекта. Это решение позволяет гибко добавлять харктеристики детали, без изменения структуры БД и механизма обработки. ИМХО - это плюс и не малый. ..И, например, запросы усложнятся только немного в плане синтаксиса, но не в плане компенации ухищрений моделирования. ... Но речь идет только о том, чтобы если есть возможность, проверить и этот подход. И тот и другой способ предпологают дополнительные трудозатраты. При этом реляционная модель давно устоялась. Так стоит ли завязываться на ОРСУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 09:30 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> А что структура? Обычная структура. Справочники (id,name) и ссылка на них в > "главной" таблице. Справочники могут быть и с деревянной "структурой" если > интересует более детальный анализ. Вопрос был задан к тому, что материалы имеют разные обозначения у разных изготовителей. Во-первых. Во-вторых, вполне себе представляема ситуация, когда вместо одного материала можно использовать другой (другие). Так что не прокатит "ссылка в главной таблице". Или опять через запятую? > Иными словами - если не нужен анализ/статистика по количеству разных > отверстий в детали, то нефига и параметр хранения такой плодить. Достаточно, > если уж сильно хочется, через запятую (дефис, иероглиф). Ага. А если статистика понадобится - конечно, проще все переписать заново. Безработицы в РФ нет и не будет. > Для решения этой задачи, неплохо бы было описать те самые "характеристики", > которые разные и которых много. А так же за чем они нужны. Ответ не принимается. Их количество понятно, изменяемость вполне можно прогнозировать. Еще варианты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 09:57 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
StalkerSНеобходимо сконструировать базу деталей. Разновидностей деталей около 50, т.е. болты, трафареты и т.д. Разумеется, они имеют разное количество характеристик. guest_20040621Вопрос был задан к тому, что материалы имеют разные обозначения у разных изготовителей. Во-первых. Во-вторых, вполне себе представляема ситуация, когда вместо одного материала можно использовать другой (другие). Так что не прокатит "ссылка в главной таблице". Или опять через запятую? Вот ты сравни вопрос автора и свое понимание вопроса. И почувствуй разницу. Где там вообще про разные взаимозаменяемые материалы? Там вообще про детали. Справочник материалов сложная штука - я это и не оспариваю. Но это целый комплекс решений, напрямую к заданному вопросу не относящийся. Там вообще не понятно, то ли эти детали делаются (производство), то ли просто учитываются (склад). guest_20040621Ага. А если статистика понадобится - конечно, проще все переписать заново. Безработицы в РФ нет и не будет. Ага. А ты хочешь один раз и на века? А за какие деньги? guest_20040621Ответ не принимается. Их количество понятно, изменяемость вполне можно прогнозировать. Еще варианты? Вона как. Ну и не принимай. Я твои вопросы тоже без предоплаты не принимаю. 8-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 10:13 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Dik76 Предложенное решение в посте 1003997 предполагает использование в рамках реляционной модели, усеченное описание детали в виде объекта. Это решение позволяет гибко добавлять харктеристики детали, без изменения структуры БД и механизма обработки. ИМХО - это плюс и не малый. Я пытался сказать, что для конкретного проекта возможен любой из предложенных вариантов в зависимости от недостатков для конкретных требований. Более того, скорее всего, вариант предолженный в посте 1003997, скорее всего, на сегодняшний день претендует на то, что реально и будет использовано. И действительно, как и для однотабличного решения структура БД при добавлении нового вида деталей не меняется. Но дело в самой этой структуре. Бросается в глаза, что характеристика это то, что претендует быть атрибутом, а в этой структуре она - значение атрибута "Имя характеристики". Это выглядит как неадекватность моделирования в РМД. Т.е. то что в ПО выглядит как элемент структуры, в этой модели выглядит как значения данных. В ОР, возможно, бы удалось оставить характеристику как атрибут объекта. Тем более Вы сами говорите про описание в виде объекта. Может быть, это было бы более адекватно. Хотя согласен, что и тут при реализации могут быть неприятные сюрпризы: на сколько хорошо поддерживается ОР на сегодняшний день тоже не очень ясно. Но ведь интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 12:25 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Вот ты сравни вопрос автора и свое понимание вопроса. И почувствуй разницу. Хех, а что мне должно мешать видеть чуть дальше вопроса? > Справочник материалов сложная штука - я это и не оспариваю. Но это целый > комплекс решений, напрямую к заданному вопросу не относящийся. Ой, да ладно, ничего там сложного нет. Нетривиально - да, громоздко - да, но сложного ничего нет. > Ага. А ты хочешь один раз и на века? А за какие деньги? Ну, на века точно не получится (imho лет на пять, в лучшем случае - на десять; а не на полгода в случае одной таблицы). Но геморрой себе не создавать на ровном месте - очень даже возможно. Кстати, практически за те же самые деньги. ;) > Вона как. Ну и не принимай. Я твои вопросы тоже без предоплаты не принимаю. 8-) $) А что, у меня были вопросы? ;)) Imho проблема в том, что ты, Member Серега, предложил слишком простое решение там, где его быть не может. На самом деле, исходных данных для проектирования нормальной (в каком угодно смысле; заметь, я не говорю про универсальную) структуры данных imho вполне достаточно. Хотя, конечно, хозяин - барин. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 13:37 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Ой, да ладно, ничего там сложного нет. Нетривиально - да, громоздко - да, но сложного ничего нет. нетривиальность + громоздкость. Не вытекает ли из этого сложность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 14:16 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Imho проблема в том, что ты, Member Серега, предложил слишком простое решение там, где его быть не может. ИМХО, Guest guest_20040621, ты видишь проблемы там, где их нет. 8-) Я всего лишь предложил осмыслить задание. Не удивлюсь, если сейчас "задача" вполне успешно решается на Екселе, и в общем то устраивает всех, но с ростом объемов... guest_20040621На самом деле, исходных данных для проектирования нормальной (в каком угодно смысле; заметь, я не говорю про универсальную) структуры данных imho вполне достаточно. Ну тогда напиши (давно прошу) про разные и многочисленные характеристики болтов и трафаретов, которые обязательно надо отразить, и для чего надо. Заметь я не утверждаю, что я однозначно прав. Может быть и нет - для меня исходных данных мало - ну тупой я. Но обычно я решаю (стараюсь по крайней мере) решать поставленные передо мной задачи, а не химеры, рожденные в моем воображении на основе житейского опыта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 14:39 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> нетривиальность + громоздкость. Не вытекает ли из этого сложность? Нет. Сложно - это, например, структура данных для контроля версий. Под нетривиальностью в данном случае имелась в виду невозможность обойтись типовыми структурами данных. Под громоздкостью - необходимость учитывать достаточно большое количество атрибутов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 14:42 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Ну тогда напиши (давно прошу) про разные и многочисленные характеристики > болтов и трафаретов, которые обязательно надо отразить, и для чего надо. Хех, да мне-то откуда знать, чего автору вопроса надо учитываеть? Может, вкусовые ощущения целевой аудитории, ассоциируемые с группой деталей? ;) Ключевой я бы считал эту фразу: "...Разумеется, они имеют разное количество характеристик...". Почему "разумеется" - непонятно, но в данном случае и неважно. Но разное количество характеристик и разнородность деталей - важно. > Но обычно я решаю (стараюсь по крайней мере) решать поставленные передо > мной задачи, а не химеры Ну, а я чего, погулять вышел? ;) ОК, формулирую задачу вопроса по-другому: описать детали с произвольными характеристиками. Что изменилось? Где химеры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 14:53 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Хех, да мне-то откуда знать, чего автору вопроса надо учитываеть? А я именно вот это и хотел только узнать у автора . guest_20040621ОК, формулирую задачу вопроса по-другому: описать детали с произвольными характеристиками. Что изменилось? Где химеры? А я сразу про свое. Что за характеристики, зачем они, как они нужны? 8-) Я понимаю к чему ты клонишь. Но все таки произвольные - это не тоже самое, что многочисленные и разнообразные. Твоя постановка тоже иногда имеет место быть. Но к счастью не так часто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 15:22 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> А я сразу про свое. Что за характеристики, зачем они, как они нужны? 8-) Я бы сказал, что это неважно, зачем именно они нужны. Они просто есть. А чего с ними потом дальше будут делать - абсолютно все равно. ;) Соблазн велик, понимаю, выделить относительно часто используемые характеристики и описать их, а остальные просто перечислить. Через запятую с тире. ;) Но в общем случае так не бывает. Т. е., возможно, такую работу удастся сдать заказчику, но он поймет, что его хм... надинамили, скажем так, очень быстро. ;) > Я понимаю к чему ты клонишь. Но все таки произвольные - это не тоже самое, > что многочисленные и разнообразные. ;)) А в чем разница? Вот если бы было так: "необходимо учитывать _ровно n характеристик_ каждой группы деталей", тогда да, это разные вещи, спору нет. Но такой фразы в вопросе нет, правда? ;) > Твоя постановка тоже иногда имеет место быть. Но к счастью не так часто. Да практически всегда только так и есть. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 15:36 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Соблазн велик, понимаю, выделить относительно часто используемые характеристики и описать их, а остальные просто перечислить. Через запятую с тире. ;) Но в общем случае так не бывает. Т. е., возможно, такую работу удастся сдать заказчику, но он поймет, что его хм... надинамили, скажем так, очень быстро. ;) Мне даже интересно стало - в какой предметной области у тебя опыт? Например супермаркет - номенклатура - десятки тысяч наименований. И что? Подробно описывать сущности "носки", "трусы", "майки" на том основании, что у них разное количество входных отверстий? 8-) А у "бананов", "картошки" и "сливы" разные природные зоны произрастания? Зачем!!!??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 15:47 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Как правило, в машиностроении для работы хватает габаритных размеров, > материала, собственно типа детали и ГОСТа. Хм... Member Серега поделится своим видением проблемы относительно материалов и типов? А сами что именно предлагаете? Ваше решение проблемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 15:58 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Мне даже интересно стало - в какой предметной области у тебя опыт? А что это меняет? > Например супермаркет - номенклатура - десятки тысяч наименований. И что? И ничего. Очень хорошо, я рад, что в супермаркетах такой ассортимент. Это не такая страшная цифра, как может показаться. > Подробно описывать сущности "носки", "трусы", "майки" на том основании, что у > них разное количество входных отверстий? 8-) А у "бананов", "картошки" и > "сливы" разные природные зоны произрастания? Зачем!!!??? Я бы не стал утрировать. Определяющего значения количество дырок в майках, носках и трусах не имеет. Но основные факторы учитывал бы. Зачем? Чтобы денег заработать. Супермаркету, разумеется. Есть зависимость между качеством товара (назовем это так, на самом деле, можно выделить кучу факторов) и ценой, правда? Ты собираешься определять ее эмпирическим путем? Или покупать и выставлять все, что можно? Огорчу: не получится ни то, ни другое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 16:06 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Определяющего значения количество дырок в майках, носках и трусах не имеет. Но основные факторы учитывал бы. Вот!!! И я про это! И я про "определяющее значение". Ты вот почему то решил, что у автора (ау-у-у-у автор!!! 8-) все характеристики имеют "определяющее значение", а я в этом усомнился. Ну приведи пример наконец, что еще разного для маек-носков, с твоей точки зрения, имеет "определяющее значение" для супермаркета. guest_20040621Есть зависимость между качеством товара (назовем это так, на самом деле, можно выделить кучу факторов) и ценой, правда? Ты собираешься определять ее эмпирическим путем? Расшифруй. 8-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 16:23 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Отсутствие опыта дествительно не влият на истинность или ложность высказывания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 16:30 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Вот!!! И я про это! И я про "определяющее значение". Ты вот почему то решил, > что у автора (ау-у-у-у автор!!! 8-) все характеристики имеют "определяющее > значение", а я в этом усомнился. Да не решал я ничего. Я просто отнесся к ним, как к равнозначным. Потому что обратного сказано нигде не было. Да и проще с точки зрения структуры завести поле маркера, чем менять размерность таблицы, если уж так хочется ранжировать параметры. > Ну приведи пример наконец, что еще разного для маек-носков, с твоей точки > зрения, имеет "определяющее значение" для супермаркета. Поскольку я не проектировал базы данных для супермаркетов, мое мнение вряд ли может служить критерием значимости параметров. Правильнее нанять контору, которая провела бы нормальное маркетинговое исследование по этому поводу. ;) Вообще, если честно, у меня утилитарный подход: носки-майки я не покупаю в супермаркетах. Так уж сложилось. Если говорить вообще о носках, для меня играли бы роль: размер, материал, изготовитель, цвет, упаковка. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 16:45 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Расшифруй. Эх, слона-то я и не приметил. ;) ОК, имелось в виду следующее: пусть есть продовольственный супермаркет и в нем бакалейный (ничего не напутал?) отдел, торгующий крупами (в частности). Я утверждаю, что есть зависимость между ассортиментом круп и прибылью, получаемой, этим отделом. Кроме того, есть зависимость между определенными параметрами (например, изготовитель, упаковка, месторасположение и пр.) и прибылью. Определить эти зависимости иначе, чем регистрируя эти параметры, нельзя. Пока писал, вспомнил хрестоматийный пример (не помню, где читал, ногами не пинать): размещение (кстати, в супермаркетах) пива рядом с детскими подгузниками увеличивало объем продаж пива. Оказалось, что подгузники покупали в основном папы, которые не отказывали себе в удовольствии купить пару пива, раз уж они пришли в магазин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 16:56 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
2 Серега: Обратите внимание на различия в переключателях поиска на этих двух страницах: IDE HDD , Компьютеры PC . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 17:06 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
>LeXa NalBat И что в этих переключателях должно заинтересовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 09:21 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
2 guest_20040621 [1010318] 1. Если ты в 5 строчках автора увидел задание на создание полноценной ERP системы с развитыми возможностями для маркетинговых исследований - флаг в руки, я не против. Я лишь усомнился в этом (исходя из основного вопроса - "создать 50 таблиц (по таблице на каждый вид), или создать одну таблицу"), и мои сомнения пока никто не развеял (да мне вобщем то по барабану 8-). 2. Ничего противоречащего моим высказываниям ты не написал. Если такой анализ должен проводиться для всех товаров, то следовательно и характеристики этих товаров должны быть идентичны. 3.Про пиво и памперсы. 8-) Ну и как ты эти взаимосвязи в базу будешь заводить? 4.Описать все многообразие мира плоскими таблицами невозможно - жизнь намного сложнее и параметры этой сложности примитивной структуризации не поддаются. Я понял твою позицию. Она имеет право на существование, точно так же как и моя. Для выбора между этими позициями информации (для меня по крайней мере) не достаточно. Посему я остаюсь при своем мнении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 09:42 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> 1. Если ты в 5 строчках автора увидел задание на создание полноценной ERP > системы с развитыми возможностями для маркетинговых исследований - флаг в > руки, я не против. ;) Хм... да нет, конечно. Если бы я говорил о ERP системе, я бы начал совсем не с характеристик и на такую мелочь, как их организация, обратил бы внимание в последнюю очередь. > 2. Ничего противоречащего моим высказываниям ты не написал. Если такой > анализ должен проводиться для всех товаров, то следовательно и > характеристики этих товаров должны быть идентичны. Очень хорошее замечание. В том-то и дело, что нет. Для разных групп товаров это будут разные (imho существенно разные) характеристики. Я бы даже сказал, что это отдельная задача - определить набор значимых характеристик. Но сначала их все равно придется регистрировать. ;) > 3.Про пиво и памперсы. 8-) Ну и как ты эти взаимосвязи в базу будешь заводить? Как обычно. Анализируем чеки, - если видим, что часто подгузники покупаются с пивом, меняем место выкладки пива и смотрим на результат. > 4.Описать все многообразие мира плоскими таблицами невозможно - жизнь > намного сложнее и параметры этой сложности примитивной структуризации не > поддаются. Кто решил, что плоскими и что структурирование примитивно? Отнюдь. Это сейчас не принципиально, для конкретного вопроса, а вообще - от задачи. Попробуй, - лично я с непреодолимыми ограничениями не сталкивался. > Я понял твою позицию. Она имеет право на существование, точно так же как и > моя. Для выбора между этими позициями информации (для меня по крайней > мере) не достаточно. Посему я остаюсь при своем мнении. ;) Хотелось предложить тебе, member Серега, начать сомневаться в существовании единственного подхода. Что, собственно, получилось. ;) А переубеждать - спасибо, я этим не занимаюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 10:18 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Dik76И что в этих переключателях должно заинтересовать?То, что они разные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 10:28 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Я бы даже сказал, что это отдельная задача - определить набор значимых характеристик. Но сначала их все равно придется регистрировать. ;) С отдельной задачей согласен. А вот "сначала их все равно придется регистрировать" нет. Ты представляешь себе объем работы по вводу может быть нужной в последствии инфы? ИМХО, нет. А ведь ее вводить надо - это тоже денег стоит, и не малых. А ее (инфу) еще и иметь надо при вводе. А на накладных ее нет. Как обычно. Анализируем чеки, - если видим, что часто подгузники покупаются с пивом, меняем место выкладки пива и смотрим на результат. Ага. А потом погода портится и закупленное вагонами пиво киснет. Или на каждом чеке и температура воздуха должна стоять с осадками. 8-) Можно еще вводить симпатичность продавщицы пивного отдела (а также ее настроение, зависящее например от месячных 8-) как параметр хранения и анализа. Хотелось предложить тебе, member Серега, начать сомневаться в существовании единственного подхода. Это я полностью переадресую тебе, Guest guest_20040621, ибо я не раз в этой ветке признавал право твоей точки зрения на существование, а вот ты упорно желаешь искать черную кошку в темной комнате, даже если ее там нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 10:42 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> А вот "сначала их все равно придется регистрировать" нет. Ты представляешь > себе объем работы по вводу может быть нужной в последствии инфы? ИМХО, нет. Да нет, вполне себе представляю. Видишь ли, в чем особенность: ассортимент супермаркета не меняется мгновенно каждый день. Т. е., новых записей в бд ежедневно появляется немного. Навскидку я бы ограничился всего парой рабочих мест и двумя операторами. В масштабах супермаркета это и затратами назвать нельзя. ;) > А ведь ее вводить надо - это тоже денег стоит, и не малых. А ее (инфу) еще и > иметь надо при вводе. А на накладных ее нет. Конечно, нет. Откуда ей там взяться? ;) > Ага. А потом погода портится и закупленное вагонами пиво киснет. ;) Супермаркет не покупает пиво вагонами, - смысла нет. > Или на каждом чеке и температура воздуха должна стоять с осадками. 8-) А что, разве я привел полный алгоритм анализа продаж? ;) > Это я полностью переадресую тебе, Guest guest_20040621, ибо я не раз в этой > ветке признавал право твоей точки зрения на существование, а вот ты упорно > желаешь искать черную кошку в темной комнате, даже если ее там нет. ;) Я ж писал, что можно обойтись и одной таблицей. Теоретически. ;) Что до меня, я _никогда_ таким решением пользоваться не буду. Дорого. Очень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 11:17 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Видишь ли, в чем особенность: ассортимент супермаркета не меняется мгновенно каждый день. Т. е., новых записей в бд ежедневно появляется немного Ассортимент и товар этого ассортимента - две большие разницы. Одинаковая водка например купленная у разных поставщиков - две разные водки. Навскидку я бы ограничился всего парой рабочих мест и двумя операторами. Навскидку только стрелять хорошо, и то только в кино. 8-) Конечно, нет. Откуда ей там взяться? ;) Как же вводить то? Супермаркет не покупает пиво вагонами, - смысла нет А чем же - ящиками или составами? 8-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 11:32 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Ассортимент и товар этого ассортимента - две большие разницы. Одинаковая > водка например купленная у разных поставщиков - две разные водки. ;) Я это и имел в виду. Я ж говорю: не проектировал я баз данных для розничной торговли и с терминологией незнаком. > Навскидку только стрелять хорошо, и то только в кино. 8-) Хм... ОК, тогда так: 1,5 минуты на обработку одной товарной позиции - imho более чем достаточно (не детализирую imho, просто поверь, что это соответствует действительности). Считаем: один оператор - 320 товарных позиций в день, два оператора - 640. Т. е. в месяц - 14080 товарных позиций. > Как же вводить то? Руками, конечно. Member Серега, диалог начинает напоминать консультацию. Не помню, чтобы я давал обязательство описать систему управления супермаркетом. Ответ на вопрос треда мы общими усилиями, надеюсь, нашли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 12:09 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Ответ на вопрос треда мы общими усилиями, надеюсь, нашли. Только судя по отсутствию автора, он видимо никому не нужен, кроме нас. 8-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 12:24 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621..Ответ на вопрос треда мы общими усилиями, надеюсь, нашли. Опубликуйте ответ пожалуйста , а то я его что то не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 15:38 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Dik76Опубликуйте ответ пожалуйста , а то я его что то не вижу. Ответ простой - делай как хочешь , лишь бы работало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2004, 16:30 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
>Только судя по отсутствию автора, он видимо никому не нужен, кроме нас. 8-) Извините за неучастие в обсуждении, так уж получилось. Спасибо всем за идеи. частично компенсирую : в данный момент эта база будет сделана на Access, но уже сейчас проектируется глобальная база всего технологического отдела, и она будет на MSSQL. По поводу характеристик для разных деталей - я вообще-то не технолог, но не думаю, что можно выделить какие-то "главные" характеристики для деталей, а остальные просто перечислить через запятую. Например сверло - имеет (чисто для примера - я не технолог) диаметр, длину, марку материала, трафарет - длину, ширину, толшину, марку материала. ВСЕ эти данные нужны для дальнейшей работы, иначе их бы никто не заносил в базу (имхо, но я спрошу это у них, не думаю, что они ответят что-то другое). База нужна именно для производства, а не для хранения - поэтому эти данные будут использоваться потом для анализа трудозатрат, стоимости производства и т.д. По всей видимости, для Access я сделаю одной таблицей, т.к. нужна эта база будет всего пару месяцев. Я нашел еще одно решение (возможно, именно это имел ввиду Guest в топике от 2 окт 04, 14:29 [1003997], может кто-то еще о нем здесь упоминал, если так, то sorry, у меня еще не так много опыта что-бы все понять с двух слов) Я имею в виду следующее : Если делать одной таблицей, то получится нечто вроде : ТЕХНОЛОГИЯ N дет. | Название | Толщина | Ширина | Длина | Диаметр | и т.д. ________________________________________________________ 1 Болт null null 20 5 2 Трафарет 10 500 900 null 3 Плита 6 100 500 null _________________________________________________________ Но можно разбить на 3 таблицы вида : ДЕТАЛИ N дет | Название _________________ 1 Болт 2 Трафарет 3 Плита _________________ ХАРАКТЕРИСТИКИ N хар. | Название __________________ 1 Толшина 2 Ширина 3 Длина 4 Диаметр __________________ ТЕХНОЛОГИЯ N дет. | N хар. | Значение __________________________ 1 3 20 1 4 5 2 1 10 2 2 500 2 3 900 3 1 6 3 2 100 3 3 500 3 правда, может возникнуть проблема, например теми характеристиками, у которых значение не числовое, а текстовое, но это можно решить просто добавив в таблицу технология это поле, в конце концов таких полей будет не более 2-3(а скорее всего и вообще не будет). В таком варианте, очень просто добавлять новые характеристики, и удалять ненужные, правда, возможно увеличиться время доступа в информации (надо 3 таблицы связывать вместо одной), зато нет null значений, которые тоже тормозят систему, так что проигрыш во времени возможно и вообще не будет заметен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2004, 11:01 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
ой, в таблицах все посползало, куда-то делись пробелы между полями, но надеюсь все равно идея понятна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2004, 11:02 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
;) Вы двигаетесь в нужном направлении, StalkerS. Стандартизуйте единицы измерения или задайте их жестко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2004, 11:22 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
да они вообщем-то и так стандартизированы давным-давно, в основном все в миллиметрах, так что проблем здесь не будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2004, 11:53 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
StalkerSЯ нашел еще одно решение (возможно, именно это имел ввиду Guest в топике от 2 окт 04, 14:29 [1003997], может кто-то еще о нем здесь упоминал, если так, то sorry, у меня еще не так много опыта что-бы все понять с двух слов) Да он это и имел ввиду. StalkerSправда, может возникнуть проблема, например теми характеристиками, у которых значение не числовое, а текстовое, но это можно решить просто добавив в таблицу технология это поле, в конце концов таких полей будет не более 2-3(а скорее всего и вообще не будет). Для этого "Техгология.Значение" можно хранить в varchar, а при обработке приводить к нужному типу (в "Характеристики" м. добавить поле тип данных). StalkerSда они вообщем-то и так стандартизированы давным-давно, в основном все в миллиметрах, так что проблем здесь не будет Я бы добавил единицу измерения в "характеристики". ИМХО: Хуже не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2004, 08:51 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
А это опять я со своим скепсисом. StalkerSПо поводу характеристик для разных деталей - я вообще-то не технолог, но не думаю, что можно выделить какие-то "главные" характеристики для деталей, а остальные просто перечислить через запятую. Например сверло - имеет (чисто для примера - я не технолог) диаметр, длину, марку материала, трафарет - длину, ширину, толшину, марку материала. ВСЕ эти данные нужны для дальнейшей работы, иначе их бы никто не заносил в базу (имхо, но я спрошу это у них, не думаю, что они ответят что-то другое). Полную информацию о детали дает только чертеж+ТУ. Для того же сверла я могу привести еще несколько параметров без готорых оно сверлить не будет. Например: вид хвостовика (с указанием номера конуса или диаметра хвостовика), шероховатость поверхности и квалитет точности рабочих и нерабочих поверхностей, способ изготовления, способ заточки и т.д. и т.п. Зачем все это в БД? Причем практически все параметры гостированы - и спецу достаточно знать этот ГОСТ и диаметр. Ддя БД достаточно указать номер чертежа (и/или сам чертеж в БД засунуть). StalkerSБаза нужна именно для производства, а не для хранения - поэтому эти данные будут использоваться потом для анализа трудозатрат, стоимости производства и т.д. Для производства сверл, трафаретов и т.д.? Или для производства с применением их? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2004, 10:49 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
> Зачем все это в БД? Хех, member Серега, чего ты к человеку пристал? - ну, нужны они ему. Нужны. > Причем практически все параметры гостированы - и спецу достаточно знать этот > ГОСТ и диаметр. А кто сказал, что они обязаны только по ГОСТу сверла делать? А если это, например, стоматологические/зуботехнические боры по специальному заказу? ;) > Ддя БД достаточно указать номер чертежа А почему ты уверен, что это не сделано? > (и/или сам чертеж в БД засунуть). Ну, так-то точно делать не следует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2004, 17:47 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
>Причем практически все параметры гостированы - и спецу достаточно знать этот ГОСТ и диаметр все никак руки не доходят задать технологам вопрос по поводу параметров деталей нужных им в базе, но возьмем к примеру швеллер. Да, в базу можно завести только ГОСТ материала и номер швеллера (ну и длину) - и что дальше, чтобы определить к примеру его вес, надо будет либо в сами госты лезть в ручную, либо заводить их в базу - а забить госты в базу - занятие не для слабонервных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2004, 21:36 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
StalkerSвсе никак руки не доходят задать технологам вопрос по поводу параметров деталей нужных им в базе, но возьмем к примеру швеллер. И чего ты тогда пишешь? Странный подход к написанию программы - спрашивать на форуме (не отвечая на встречные вопросы), но не советоваться с заказчиком. Я понял, что уже надоел всем. Все умолкаю - делай как хочешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2004, 08:57 |
|
||
|
организация структуры БД
|
|||
|---|---|---|---|
|
#18+
Просто когда мне обьясняли задачу, мне даже и не приходило в голову выделять какие-то основные характеристики. Они сказали - надо хранить много деталей с разным количеством параметров, и вопрос я задавал исходя именно из этой постановки задачи. В принципе, наиболее рациональным решением мне кажется тот вариант, который я описал выше, но вопрос про нужность или ненужность характеристик я все-таки им задам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2004, 16:00 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1546252]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
84ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
89ms |
get tp. blocked users: |
2ms |
| others: | 252ms |
| total: | 476ms |

| 0 / 0 |
