Страница 1 из 1

Неявная связь между таблицами?

Добавлено: 20 авг 2007, 17:13
Kotъ-Begemotъ
Заранее извиняюсь, кое-что из Delphi но к сути вопроса эти комментарии особо отношения не имеют, просто привёт для "полноты картины" для любознательных :)

Вот есть две таблицы - исполнителей, ну, пусть Works и заказов (пусть Orders)
Works три поля
WorkID (понятно, первичный ключ)
WorkStatus (в каком состоянии находится)
и WorkName (понятно)
а Orders - ну для нашего примера пусть
OrderID,
OrderType,
OrderStatus
и WorkID (кто выполняет - может быть и null или 0).

Таблицы в общем случае между собой не завязаны жестко. Но вот, конкретный заказ отдаётся конкретному человеку (для простоты давайте считать, что одному человеку может быть отдан только один заказ и при отдаче другого, первый автоматом считается выполенным, так что в одно время для одного исполнителя может быть только один активный заказ - то есть заказ с неким статусом OrderStatus=2).

Вопрос собственно в следующем. Исполнители отображаются визуально (в моём случае с помощью DBCtrlGrig хотя МЕФ). И надо по разному отображать людей выполняющих заказы разного типа (OrderType). Причём ни Calculated ни Lookup поля не проходят (если интересно, то отрисовка DBCtrlGrid делается в процедуре OnPaintPanel и проверка внутри этой процедуры вычисляемых или lookup полей даёт непредсказуемые результаты, хотя в целом это тоже МЕФ). Так вот вопрос - как грамотно установить эту самую связь между типом заказа, находящегося в определённом состоянии (выполняется), и принадлежащего определённому исполнителю и состоянием исполнителя?
Пусть список исполнителей получаем запросом. Правильно ли будет цеплять в запросе поля из таблицы Orders где по условию отбирать нужные данные?

Код: Выделить всё

select wk.UserID, wk.UserName, od.OrderID, od.OrderType
from Works wk
left join Orders od
 on (od.WorkID=wk.WorkID and od.OrderStatus=2)
и затем анализировать при визуализации полученные значения, проверяя их на null (если для данного исполнителя активных заказов нет, будет ведь null насколько я понимаю в полях od.OrderID, od.OrderType?

Подскажите я в правильном направлении думаю, или не учитываю каких-то возможностей РСУБД? В данном случае это будет FB 2.0

Re: Неявная связь между таблицами?

Добавлено: 20 авг 2007, 18:22
WildSery
Kotъ-Begemotъ писал(а):И надо по разному отображать людей выполняющих заказы разного типа
Моя фантазия рисует мульён вариантов. Чего надо-то?

Re: Неявная связь между таблицами?

Добавлено: 20 авг 2007, 18:32
Kotъ-Begemotъ
WildSery писал(а):
Kotъ-Begemotъ писал(а):И надо по разному отображать людей выполняющих заказы разного типа
Моя фантазия рисует мульён вариантов. Чего надо-то?
Извини, наверное неясно изложил. Попробую еще раз. Есть таблица Works которая визуализирована. То есть её изменения должны оперативно отображаться. Количество записей в ней небольшое - ну пусть для теории 1000 записей (реально меньше - под 500, но "на вырост" так сказать :) И есть куча других таблиц, та же таблица заказов, и другие вспомогательные таблицы. Сталкиваюсь с тем, что надо оттуда тянуть поля, потому что по-разному нужно визуализировать записи таблицы Works для разных сочетаний значений в "неявно связанных" таблицах...
Поскольку надо будет часто запрашивать данные у Works, хотелось бы вроде запрос попроще сделать. Но получается что надо делать запрос, цепляющий все поля, влияющие на визуализацию Work из всех таблиц, в которых они присутствуют... получается уже совсем не такой маленький и быстрый запро. Ведь это Works маленькая, а та же Orders одна уже под 100000 записей... А есть еще и другие таблицы...

Добавлено: 20 авг 2007, 18:35
kdv
по-моему вы пытаетесь смешать торговую систему и crm. дело хорошее, но в этом случае рекомендую посмотреть на разные crm, чтобы не сочинять велосипед.
Ведь это Works маленькая, а та же Orders одна уже под 100000 записей... А есть еще и другие таблицы...
фигня какая то. по идее исполнитель должен видеть как свои так и незанятые заказы. Это не проблема, и не 100к заказов. И так далее...

И вообще. ну 100к записей. Эка невидаль. конечно, если мощный запрос написать, то можно сделать чтобы он и полчаса выполнялся. Это, конечно, если постараться...

Добавлено: 20 авг 2007, 18:42
Kotъ-Begemotъ
kdv писал(а):по-моему вы пытаетесь смешать торговую систему и crm. дело хорошее, но в этом случае рекомендую посмотреть на разные crm, чтобы не сочинять велосипед.
Да, пытаюсь смешать. Это менеджер такси. Там действительно есть (в упрощенном варианте, конечно) CRM да много еще чего...
kdv писал(а):фигня какая то. по идее исполнитель должен видеть как свои так и незанятые заказы. Это не проблема, и не 100к заказов. И так далее...
Конечно отображаться будут не 100000 заказов, но в случае запроса подобного тому что я описАл типа

select wk.WorkID, ... od.OrderType...
с join к Orders

таблица заказов ведь будет полностью лопатиться на предмет соответствия условиям? Или я ошибаюсь?

Добавлено: 21 авг 2007, 00:36
kdv
таблица заказов ведь будет полностью лопатиться на предмет соответствия условиям? Или я ошибаюсь?
а что, каждому оператоу надо видеть ВСЕ?
или, джойн таблиц по 100к записей стал медленно работать?
www.ibase.ru/devinfo/joins.htm

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

Добавлено: 21 авг 2007, 00:46
Kotъ-Begemotъ
kdv писал(а):а что, каждому оператоу надо видеть ВСЕ?
или, джойн таблиц по 100к записей стал медленно работать?
www.ibase.ru/devinfo/joins.htm
ты сначала попробуй, а потом спрашивай. теоретизировать можно долго и безуспешно.
Нет конечно, оператору видеть надо как раз очень мало из таблицы заказов! Просто таблица достаточно большая, и если я добавлю в "основную" таблицу (водителей, которую как раз нужно видеть ну, скажем почти всю, а это сейчас не менее 200 записей) кучу полей связанных по join с относительно большой таблицей заказов, я как раз и боюсь что это будет "узким местом", поэтому и спрашиваю... Пробовать конечно буду, пока "набираю базу" - читаю Х. Борри по FB...

Добавлено: 21 авг 2007, 07:42
stix-s
Ну, для отчета, Orders может и надо всю дергать, хотя есть такое понятие, как отчетный период
а в текущем дне вчерашние заказы оператору вроде как и не к чему?
ЗЫ
А
по разному
это что значит? цветом выделять?

Добавлено: 21 авг 2007, 09:53
WildSery
Kotъ-Begemotъ писал(а):кучу полей связанных по join с относительно большой таблицей заказов, я как раз и боюсь что это будет "узким местом", поэтому и спрашиваю...
Мосье кажись не понимает, что такое индексы и как они работают.
Вот скажи. У меня есть две таблицы - 100 записей и 10млн записей.
Заметишь ли ты на глаз разницу выбора по первичному ключу из этих таблиц, скажем, 10 записей? Ответ обоснуй для себя :) Можешь даже попробовать, чтобы, так сказать, "пошшупать" живьём.

Добавлено: 21 авг 2007, 15:39
Kotъ-Begemotъ
по разному
это что значит? цветом выделять?[/quote]

Ой, чего только не значит... И цветом, и цветом шрифта надписей, и дополнительные символы показывать... То же кстати и для окна заказов - и цвет фона и цвет текста, и куча дополнительных символов...

Добавлено: 21 авг 2007, 15:40
Kotъ-Begemotъ
WildSery писал(а):Мосье кажись не понимает, что такое индексы и как они работают.
Вот скажи. У меня есть две таблицы - 100 записей и 10млн записей.
Заметишь ли ты на глаз разницу выбора по первичному ключу из этих таблиц, скажем, 10 записей? Ответ обоснуй для себя :) Можешь даже попробовать, чтобы, так сказать, "пошшупать" живьём.
Да, мосье пока "плавает" в этом деле... Про что ты говоришь, действительно разницы не будет при выборе по PK. С join вроде посложнее ситуация, поэтому и спросил. Буду учиться...

Добавлено: 21 авг 2007, 16:16
WildSery
Kotъ-Begemotъ писал(а):С join вроде посложнее ситуация, поэтому и спросил. Буду учиться...
:) А как, по-твоему, join работает? По индексу и ищет.
Перечитай эту статейку ещё разок ;)