Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
02.07.2004, 13:28
|
|||
|---|---|---|---|
как лучше развязать многие-ко-многим (практика) |
|||
|
#18+
есть распространенная схема клиенты и контракты, контракты могут быть многосторонними, т.е. в одном контракте учавствуют несколько клиентов, и каждый клиент может учавствовать в нескольких контрактах практически клиент на контракт как минимум в половине случаев 1, и в 99,999% не больше 8, никто из заказчиков программы не слышал что бы было больше 10. так вот меня интересует, использовал ли кто-нибудь в такой ситуации ораклиные массивы как поле таблицы? или всегда классику с 3-й таблицей? а если использовал, то чем черевато? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.07.2004, 14:27
|
|||
|---|---|---|---|
|
|||
как лучше развязать многие-ко-многим (практика) |
|||
|
#18+
Самое главное что произойдет - не будет работать контроль ссылочной целостности... И только по этой причине я бы не советовал использовать такой подход ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.07.2004, 20:23
|
|||
|---|---|---|---|
как лучше развязать многие-ко-многим (практика) |
|||
|
#18+
массивы как поле таблицы - это уже иерархические СУБД (не реляционные) При этом подходе лучше всего использовать такие СУБД как Demos ; Mumps, в оракле - более удачно будет через 3-ю таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
04.07.2004, 22:02
|
|||
|---|---|---|---|
как лучше развязать многие-ко-многим (практика) |
|||
|
#18+
Если вы в качестве массивов имете ввиду вложенные таблицы, то это все равно третья таблица (NESTED). Хотя для программирования она не имеет значения, но для администрирования может иметь. А если фиксированный массив, то какой? Вдруг в каком-то случае 10 не хватит? Отход от реляционности в Оракле затрудняет интерпретацию (сложнее разобраться в схеме), усложняет извлечение информации (запросы выглядят сложнее, возможно оптимизация ухудшится), про декларативные ограничения целостности уже сказали. Программирование тоже, скорее всего окажется сложнее – придется работать с коллекциями. Могут усложниться и вопросы администрирования. Например, оценка табл по объему может стать посложнее. А в чем выигрыш? В схеме меньше таблиц? Да но, они сложнее по структуре. Упростится что-то в программировании? Если в чем-то и упростится, то в другом может усложниться. В общем, рискованно это. А есть еще и баги. Особенно если отходить от классики. Там меньше народу на баги все это проверяло. И, скорее всего, существуют еще какие-то недостатки, которые обладают склонностью обнаруживаться в самый неподходящий момент. А классика – есть классика. Для отхода от нее должны быть очень веские причины в общем случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=32&tablet=1&tid=1546380]: |
0ms |
get settings: |
7ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
49ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 219ms |
| total: | 344ms |

| 0 / 0 |
