|
|
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинэто отношение владения, по которому [в том числе] однозначно строятся права доступа. Я предложил универсальную схему для прав доступа, в которой может меняться все. В реале так и происходит. А ТС просто не может сформулировать задачу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2013, 17:00 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
_модКот Матроскинэто отношение владения, по которому [в том числе] однозначно строятся права доступа. Я предложил универсальную схему для прав доступа, в которой может меняться все. Именно поэтому она не явлется хорошим решением для описанного случая - тут не "может меняться все", гибкость решения не приносит пользы, хотя по прежнему за нее надо платить свою цену (в данном случае - дополнительным обьектом базы, дополнительным обьемом данных, дополнительным join'ом в коде, необходимостью проверок "нет ли двух владельцев у обьекта?" и т.п.) Логика "Для того чтобы вскипятить чайник, нужно налить в него воды, включить плиту, поставить чайник и дождаться кипения. Если в чайнике есть вода - выливаем ее и используем универсальное решение" - она плохая, негодная ;) Проектировщик сэкономил свои усилия, и вместо того чтобы подумать над конкретной задачей применил "универсальное решение"(tm), цену которого будут платить разработчики, dba и пользователи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2013, 17:18 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинИменно поэтому она не явлется хорошим решением для описанного случая Этот случай типовой и решение тоже типовое. Отдельная таблица с индексами по user и объект - самый эффективный способ. Все остальное дороже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2013, 17:51 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
_модКот МатроскинИменно поэтому она не явлется хорошим решением для описанного случая . Отдельная таблица с индексами по user и объект - самый эффективный способ. Все остальное дороже. ээ, эффективный в чем? у меня получилось, (user - ~5К записей, Object ~220k) что запрос Код: sql 1. 2. 3. 4. 5. 6. 7. примерно в полтора раза уступает Код: sql 1. 2. 3. 4. 5. и такая же картинка - при поиске по ObjectID Единственно когда второй запрос проигрывает - когда нет индексов на таблицах object1, object2 (поскольку происходит table scan, и по object2 за счет лишнего поля надо просто больше страниц читать.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2013, 18:44 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, пардон, сорвалось сообщение раньше, не почистил второй запрос с именами таблиц и хинтом- хинт там роли не играет, что с хинтом что без хинта результат одинаковый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2013, 18:47 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
sender219, Блин. Или я туплю или ... А описание модели где? Или это озвученное выше "Пользователи - Поставщики - Поставки - Заказы (клиентские)" ? Если озвученное выше то уберите из providers user_id. Сделайте таблицу providers_user (provider_id, user_id, ...). Можете в нее еще добавить дату начала и дату конца, тогда сможете организовать историю изменения пользователя для данного поставщика. В таблице orders поле purchase_id явно лишнее, можете смело убирать. И если приводите схему то отображайте все элементы таблиц, это избавит от непоняток (в данном случае я непытаюсь угадать что у вас там еще скрыто). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2013, 18:56 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
Злой Бобр...Сделайте таблицу providers_user (provider_id, user_id, ...)... Зачем? Если отношение между ними 1-М, зачем мне переходить на М-М? По условию поставщик принадлежит только одному пользователю. И у одного пользователя может быть много собственных (личных) поставщиков. Злой Бобр...В таблице orders поле purchase_id явно лишнее, можете смело убирать... А это зачем? Если по каждой поставке (purchases) может быть ноль или М заказов (orders). В целом картина такова: каждый пользователь системы ведёт собственный каталог поставщиков. По каждому своему поставщику пользователь формирует поставки. По каждой поставке может быть сформировано М заказов. Злой Бобр...И если приводите схему то отображайте все элементы таблиц, это избавит от непоняток (в данном случае я непытаюсь угадать что у вас там еще скрыто). Скрыты атрибуты, не имеющие отношения к вопросу. Свойства пользователя, поставщика и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 08:19 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин При условии: По условию поставщик принадлежит только одному пользователю вы правы. Но условие сомнительное :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 09:29 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
_мод...Но условие сомнительное :)... Согласен. Вообще система достаточно специфична. Именно поэтому и старался здесь абстрагироваться от предметной области, с таблицами A, B, C ... N. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 09:43 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
sender219 Вообще система достаточно специфична. Такие системы крайняя редкость. Не думаю, что ваша к ним принадлежит. Поэтому и нужно применять типовые решения. зы Как правило, юзер, создавший объект, фиксируется в аудите. Этим можно воспользоваться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 10:37 |
|
||
|
Модель связанных объектов. Проблемы выборки
|
|||
|---|---|---|---|
|
#18+
sender219Злой Бобр...Сделайте таблицу providers_user (provider_id, user_id, ...)... Зачем? Если отношение между ними 1-М, зачем мне переходить на М-М? По условию поставщик принадлежит только одному пользователю. И у одного пользователя может быть много собственных (личных) поставщиков. Зачем - я написал выше (что б видеть историю если у поставщика меняется пользователь). Но если вас устраивает что при изменении пользователя вы тупо перепишите поля таблицы (вместо Петров напишете в ФИО Сидоров) - невопрос, это ваша кухня и вам там рулить. Если считаете что пользователь будет жить вечно - это тоже ваше дело. Я вовсе не претендую на мнение последней инстанции. Все что тут пишется носит лишь рекомендательный характер. Конечный выбор за вами. sender219Злой Бобр...В таблице orders поле purchase_id явно лишнее, можете смело убирать... А это зачем? Если по каждой поставке (purchases) может быть ноль или М заказов (orders). В целом картина такова: каждый пользователь системы ведёт собственный каталог поставщиков. По каждому своему поставщику пользователь формирует поставки. По каждой поставке может быть сформировано М заказов. Ну тогда я неправильно понял смысл поставки. У вас это оказывается сводный заказ по клиентам, а я "телепартировал" что это аналог Партии. Увы, отсутствие описания дает подобные казусы. sender219Злой Бобр...И если приводите схему то отображайте все элементы таблиц, это избавит от непоняток (в данном случае я непытаюсь угадать что у вас там еще скрыто). Скрыты атрибуты, не имеющие отношения к вопросу. Свойства пользователя, поставщика и т.д. Опять же это лишь рекомендация. Хотите удивляться почему вам рекомендуют то что явно невписывается в вашу задачу - можете и дальше вырывать куски из контекста, а мы будем "телепартировать". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 16:08 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1541028]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
13ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 10ms |
| total: | 149ms |

| 0 / 0 |

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