|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
День добрый. Хотелось бы услышать ваши мнения по поводу следующей задачи: Есть система в которой сущности создаются динамически ( т.е. проетируются в этойже системе)...из атрибутов сущности найти кандидата на первичный ключ не всегда удается. Поэтому принято решение использовать сурогатный ключ. Работаю на СУБД Oracle, поэтому для генерации ключа использую последовательность.....подскажите что лучше для каждой сущности создавать свою последовательность или пользоваться одной (т.е. в системе для ID использовать одну или ряд последовательностей) если кто-то задавался подобным вопросом подскажите как реализовали? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 10:42 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
student42, Если связи будут реализованы ТОЛЬКО через суррогатный ключ, то все окончиться плачевно (если система будет сильносвязной). Суррогат лучше использовать как ровгуид. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 13:12 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
Расскажите о необходимости динамического создания сущностей. Опционально: кто научил вас этой ахинее? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 15:57 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
student42, откойте для себя наконец Guid же, и займитесь тем за что платит заказчик а не "генерацией используя последовательность". ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 16:57 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
guest_20040621Расскажите о необходимости динамического создания сущностей. Опционально: кто научил вас этой ахинее? Допустим невозможнсть четкой предварительной классификации сущностей. Например, в Процессе участвуют Вход, Процессор, Выход. Но что это именно зависит от отрасли. Все эти понятия являются точкой входа в множественный классификатор, а сами сущности классифицируемые этими понятиями (как Материал, Обрудование,Специалист..........) появятся в модели позже (кое-что прямо при процессе внедрения). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 18:20 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
> Допустим невозможнсть четкой предварительной классификации сущностей. Не канает. Модель может быть построена в общем виде, тем более, если речь идет о процессах и классификации. Можно порекомендовать более формально подходить к классификации, - это чуть сложнее, чем обычно принято, но окупает себя. Еще варианты? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 19:00 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
guest_20040621> Допустим невозможнсть четкой предварительной классификации сущностей. Не канает. Модель может быть построена в общем виде, тем более, если речь идет о процессах и классификации. Можно порекомендовать более формально подходить к классификации, - это чуть сложнее, чем обычно принято, но окупает себя. Еще варианты? Поговори немного о "не канает", интересно. Допустим мне абсолютно пофигу как называется процессор - Инструмент, Оснастка, Учитель, Корова и т.д., важно что они являются процессорами процесса. Но я н могу перечислить все возможные типы процессров. Вот модельщик и создает сущности которые ему нужны для описания предмета и классифицирует их как процессор. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 19:12 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
> Но я н могу перечислить все возможные типы процессров. Типы - можете легко. Единственный переход, который потребуется - уникальные особенности типа. И для этого нет необходимости создавать сущности динамически, обычная эволюция структуры данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 21:09 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
guest почти прав. Действительно, большинство сущностей (в т.ч. и процессоры) правильнее продумать сразу и не городить динамический огород. Другими словами, сущности - работа разработчика, а не обслуживающего персонала. Однако ж, с другой руки, бывают ситуации, когда динамические объекты данных все таки требуются. Например, если система должна предоставлять некоторые классификаторы, каждый из элементов которых должен быть определен юзером. imho, насчет процессоров Сахават погорячился. Правильно определенный объект процессор нормально так работает без динамических объектов и как станок и как парикмахер и как номер в отеле (хотя у него, Сахавата то бишь) опыта в этом деле больше, чем у меня. В адрес Осака: guid отнюдь не идеальное решение. Последовательности целочисленных величин по подавляющему большинству критериев намного лучше. Ну и наконец, по теме топика: для каждой сущности правильнее создавать собственное пространство идентификаторов. Переводя на язык оракл, для каждой - свой sequence. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 22:55 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
sobolevВ адрес Осака: guid отнюдь не идеальное решение. Последовательности целочисленных величин по подавляющему большинству критериев намного лучше. а можно хотя-бы второе преимущество назвать, плз. Первое понятно, размер. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 23:00 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
Одного размера вполне достаточно. Можно попробовать и второе - я не уверен, что время генерации uuid'а является приемлемым во всех случаях. Возвращаясь к размеру: не забываем про то, что это поле с uuid'ом практически всегда индексируется. Плюс к тому, когда мы строим в памяти список таких идентификаторов, то время поиска по этому списку может зашкаливать за разумные пределы (я, конечно, говорю о списках размером в десятки тысяч элементов и более). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 23:27 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
iscrafmsobolevВ адрес Осака: guid отнюдь не идеальное решение. Последовательности целочисленных величин по подавляющему большинству критериев намного лучше. а можно хотя-бы второе преимущество назвать, плз. Первое понятно, размер. Еще один: больше времени на отладку уходит (запомнить/записать) uuid - задача не для слабонервных. Не забываем, что один из сильных аргументов в пользу 1це - быстрая разработка. Так как этот продакт юзает uuid'ы, то из названного преимущества вычитаем упомянутую сложность (надеюсь, она - единственная). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 23:45 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
sobolevОдного размера вполне достаточно. Можно попробовать и второе - я не уверен, что время генерации uuid'а является приемлемым во всех случаях. на вскидку: 100000 записей 3s828ms - guid 3s797ms - int Или речь идет о системах реального времени? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2010, 23:58 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
> Например, если система должна предоставлять некоторые классификаторы, каждый из элементов > которых должен быть определен юзером. Простите, но на мой взгляд это глупость. Никогда, ни при каких обстоятельствах юзеры не должны иметь возможность что-то определять. Задача максимальной сложности для юзера - добавление данных. Причем, под жестким контролем. Правила классификации - вообще говоря, отдельная задача. И я бы не назвал ее тривиальной. Фишка в том, что ее решение предполагает использование по крайней мере фрагментов семантических структур - от словарей до предикат. Вы себе представляете формальные правила классификации? > для каждой сущности правильнее создавать собственное пространство идентификаторов. Не обязательно. Смысл плодить последовательности, если они фактически не будут использоваться? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 00:00 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
guest_20040621> Например, если система должна предоставлять некоторые классификаторы, каждый из элементов > которых должен быть определен юзером. Простите, но на мой взгляд это глупость. Никогда, ни при каких обстоятельствах юзеры не должны иметь возможность что-то определять. Задача максимальной сложности для юзера - добавление данных. Причем, под жестким контролем. Правила классификации - вообще говоря, отдельная задача. И я бы не назвал ее тривиальной. Фишка в том, что ее решение предполагает использование по крайней мере фрагментов семантических структур - от словарей до предикат. Вы себе представляете формальные правила классификации? > для каждой сущности правильнее создавать собственное пространство идентификаторов. Не обязательно. Смысл плодить последовательности, если они фактически не будут использоваться? Коллеги спасибо за предоставленные варианты. Очень поучительно. Хочу поддержать guest_20040621...как мне кажет он ближе к истине. Обратно же, это субъективно. Если описать более подробно то система действительно динамическая...причем создаваемые сущности являются физическими сегментами некоторого табличного пространства. Привожу примерную диаграмму системы.....прошу прощения за безобразное исполнение..но думаю смысл будет понятен. Еще раз зачечу...что структура динамическая....и заказчик должен иметьт возможность управлять сущностями...т.е. предметная область не определена рамками. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 02:35 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
student42, стандартная просьба: пожалуйста, не приводите ваш вариант решения, сформулируйте исходную задачу. Очень сложно догадываться, что именно вам нужно и почему выбрано именно такое решение. Кроме того, если вы написали "объект", расшифруйте, какой нотации соответствует его определение (или, если не соответствует никакой, объясните его физический смысл). Поясните природу классификатора, совершенно не понятен смысл его связи с КЛАДР (кстати, пока не поздно, уберите прямые связи, ничего, кроме головной боли, от прямого использования внешних классификаторов вы не получите). На вашей схеме нет собственно сущностей, которые вы собираетесь классифицировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 02:49 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
iscrafmsobolevОдного размера вполне достаточно. Можно попробовать и второе - я не уверен, что время генерации uuid'а является приемлемым во всех случаях. на вскидку: 100000 записей 3s828ms - guid 3s797ms - int Или речь идет о системах реального времени? Спасибо за цифры. К своему стыду я так и не удосужился посчитать. Кстати, вы профилировали чистое процессорное время или просто засекли начало-конец? Будем считать что я привел тупой аргумент. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 09:37 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
sobolevСпасибо за цифры. К своему стыду я так и не удосужился посчитать. Кстати, вы профилировали чистое процессорное время или просто засекли начало-конец? я просто взял СУБД, создал в ней 2 таблички: одну с GUID в качестве PK, другую с autoinc. Т.е. это время с учетом построения индекса. Сделал процедуру, которая вставляет в таблички по 100000 записей. Запустил и посмотрел что сказал профайлер о времени отработки. Подобные и эксперименты и реальные замеры, я много раз давно проделывал, когда читал различные блоги, где писАлось, что GUID в качестве PK является убийством для БД. Но как оказывалось в итоге, все эти тексты были просто многократной перепечаткой сказанной однажды кем-то глупости. А вот преимуществ предостаточно. Правда в распределенных системах и многозвенных, которыми я, в основном, занимаюсь. Я бы сказал , что следование сказанной однажды кем-то глупости ничего кроме множества бессмысленной и ненужной работы не приносит. Захватывающие саги о каки-то диапазонах, префиксах и прочих надуманных на пустом месте алгоритмах просто поражают воображение. Нужно просто решать задачи проще. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 10:38 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
student42Если описать более подробно то система действительно динамическая...причем создаваемые сущности являются физическими сегментами некоторого табличного пространства. Привожу примерную диаграмму системы..... здесь не видно ничего динамического. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 10:40 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
iscrafm Я бы сказал , что следование сказанной однажды кем-то глупости ничего кроме множества бессмысленной и ненужной работы не приносит. Ну чисто гуид для связей приносит свои сложности с лукапом. Смотри, Квалификация(ИД,Наим,...) Специальность(ИД,Наим...) Специалист(Квалификация, Специальность,...) ФизЛицо(ИД, Наим,...) Сотрудник(ФилЛицо,.....) Компетенция сотрудника(Сотрудник, Специалист,...) .... Сложность лукапа :)все растет и растет, а если можно было использовать миграцию ключей то все бы упрощалось (пришлось ввести) к ГОСТ20040621, ну согласись, что вышеперечисленные процессоры ну очень уж отличаются что бы их залить в одну структуру - процессоры ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 15:14 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
Классификатор типизирует типы :) (доопределяет семантику с помощью новых свойств = путь от вершины множ классификатора до типа) А типизация связей производится отдельно (по типу ссылки и ролям связанных типов в связи). Методы пишутся с учетом этих дженерик вещей. Эти 3 фундаментальных вещи дают возможность оставить уточнение списка и сосава сущностей модельщику. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 15:23 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
т.е. наследуемость с точностью (изоморфность с точностью, подобность с точностью) СТРУКТУР ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 15:25 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
ViPRos, ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 15:28 |
|
Суроватный ключ для сущности...?
|
|||
---|---|---|---|
#18+
ViPRos, ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2010, 15:31 |
|
|
start [/forum/topic.php?fid=33&msg=36929487&tid=1548187]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 142ms |
0 / 0 |