Хранение списка услуг

← →
Добежал (2009-01-12 12:33) [0]

Есть некие услуги, каждой услуге соответствует свой код.

В настройках программы задают соответствие кода услуги и некоторых параметров, которые и определяют порядок выполнения услуги.

Вопрос в том, как хранить мульти-услуги, то есть список услуг. С одной стороны, в программе нужно предусмотреть понятный и доступный механизм задачи соответствия кода услуги и служебных параметров. С другой, получив извне некую информацию (мульти-код?) - программа должна понять какой набор услуг имеется в виду.

Стандартное решенение - игра в биты и байты. Например, ограничить количество возможных услуг числом 255 (более-менее приемлимо). Но тогда в обычный integer влезет максимум набор 4-ех услуг, это уже не приемлимо. Int64 особо дело также не спасет.

Плюс встает вопрос сохранения, допустим, статистики о работе системы. Как в БД хранить набор услуг. БД интересуют пока FB / SQLite, но с расчетом и на другие хранилища. Можно ли в поисковом запросе выделить определенные биты в числе, например, список записей, где присутствует услуга с кодом $A4 ?

С одной стороны, формат записи должен быть человекодоступным и понятным, так как коды поступают извне и вводятся человеком. С другой, удобный для обработки программно и в частности на SQL серверах.

Какие есть варианты решения проблемы, кто сталкивался может? По всему очевидно вопрос не уникальный, должны быть, наверное, выработаны общие решения?

← →
clickmaker © (2009-01-12 12:46) [1]

> как хранить мульти-услуги, то есть список услуг

а в чем проблема?
ServiceID | ServiceName

← →
clickmaker © (2009-01-12 12:48) [2]

> Можно ли в поисковом запросе выделить определенные биты
> в числе, например, список записей, где присутствует услуга
> с кодом $A4 ?

where SomeField & 164 <> 0

← →
Добежал (2009-01-12 13:05) [3]

> а в чем проблема?
> ServiceID | ServiceName

не понял ответа.
Впрочем, есть подозрение, что это ты просто не вчитался в вопрос.

> where SomeField & 164 <> 0

а это входит в стандарт SQL? Поддерживает ли FB / SQLite такие формы записи? Не тормозит ли это сильно выборку, не "убивает" ли это индексы по полю?

← →
Правильный$Вася (2009-01-12 13:09) [4]

классический подход
клиент - услуга, многие ко многим, 3 таблицы
и никаких битовых кодирований

← →
clickmaker © (2009-01-12 13:10) [5]

> а это входит в стандарт SQL?

да

← →
Дуб © (2009-01-12 13:11) [6]

> > ServiceID | ServiceName
>
>
> не понял ответа.

Многие ко многим через еще одну таблицу.

← →
clickmaker © (2009-01-12 13:12) [7]

> не понял ответа

а что тогда "набор услуг"?

← →
Добежал (2009-01-12 13:27) [8]

Я не понял что такое:

ServiceID | ServiceName

Код услуги, название услуги? И в чем смысл, чтобы просто не оперировать строчками?

Вопрос не в этом совсем. Сейчас по-другому попытаюсь объяснить.

← →
Добежал (2009-01-12 13:46) [9]

Так будет проще, я думаю.
Итак, как дело обстоит сейчас:

Извне поступает код услуги, программа по этому коду ищет некую служебную информацию об этой услуге и выполняет некую операцию, это уже не так важно.

Что нужно сейчас: уметь передавать набор услуг. То есть, допустим есть услуга с кодом $01 и кодом $02. Клиент может выбрать любое сочетание услуг, в данном случае три варианта: только услугу $01, только услугу $02 и обе эти услуги вместе.
Сама передача извне не принципиальна, вопрос в том как хранить это в программе и в базе данных. Хранение в программе принципиально, так как это стандартизированная структура, которую могут получить внешние плагины, написанные не на Delphi. Сейчас это аля:

TClientInfo = packed record ServiceCode: integer; ...

Касаемо хранения в БД должна быть такая структура, которая позволяет нормально оперировать с кодами. На вскидку как минимум узнать допустим сколько клиентов заказывали услугу $4A. Это, естественно, все клиенты, которые непосредственно заказывали только услугу $4A и все те, которые заказывали услугу $4A вместе с другими услугами.

Способ аля where SomeField & 164 <> 0 мне лично кажется каким-то неправильным, кривоватым. Плюс он не решает проблему все равно, в том же 32-ух битном целом уместится максимум список из 4-ех услуг (если ограничить коды услуг диапазоном 1..255).

← →
Дуб © (2009-01-12 13:51) [10]

> Плюс он не решает проблему все равно, в том же 32-ух битном
> целом уместится максимум список из 4-ех услуг (если ограничить
> коды услуг диапазоном 1..255).

Если бит это услуга, то 32 услуги.

Но все-таки не ясно, чем не нравится свяка многие ко многим.

← →
Медвежонок Пятачок © (2009-01-12 13:57) [11]

если мало бит в целых - есть строки с символами

← →
clickmaker © (2009-01-12 14:18) [12]

> Что нужно сейчас: уметь передавать набор услуг. То есть,
> допустим есть услуга с кодом $01 и кодом $02. Клиент может
> выбрать любое сочетание услуг, в данном случае три варианта:
> только услугу $01, только услугу $02 и обе эти услуги вместе

where ServiceID in (1, 2)
либо
where ServiceID = 1 or ServiceID = 2

динамический запрос, короче

← →
Добежал (2009-01-12 14:39) [13]

> Если бит это услуга, то 32 услуги.

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

> Но все-таки не ясно, чем не нравится свяка многие ко многим.

тем, что я не понимаю что вы имеете в виду.

> where ServiceID in (1, 2)
> либо
> where ServiceID = 1 or ServiceID = 2

эээ. Это прекрасно, но как в поле ServiceID будет храниться информация о том, что клиент выбрал и первую услугу, и вторую тоже?

← →
clickmaker © (2009-01-12 14:41) [14]

> как в поле ServiceID будет храниться информация о том, что
> клиент выбрал и первую услугу, и вторую тоже?

то есть?
в поле хранится ID
а то что клиент выбрал - это условие отбора

вопросы все более непонятные...

← →
Jeer © (2009-01-12 14:44) [15]

Бред, какой-то, посленовогодний.
Список услуг.. хм
Да храни этот список и последовательность их выполнения как хочешь, хоть так:
01;123;456;4; etc
В чем проблема-то ?

← →
Jeer © (2009-01-12 14:45) [16]

Это если список услуг линейный по последовательности выполнения.
Если "ветвистый", то и храни в "ветвистом" виде.
В базу все это может перекочевать в соответствии с действиями "парсера" по разбору услуг на запчасти.

← →
clickmaker © (2009-01-12 14:46) [17]

Удалено модератором

← →
Jeer © (2009-01-12 14:48) [18]

Удалено модератором

← →
clickmaker © (2009-01-12 14:50) [19]

Удалено модератором

← →
Добежал (2009-01-12 15:15) [20]

> в поле хранится ID
> а то что клиент выбрал - это условие отбора
> вопросы все более непонятные...

хм... Я в свою очередь также вообще не понял, что ты сказал.
Давай чисто техническим языком.

У каждой услуги есть свой код. Хранилась информация раньше так:

TClientInfo = packed record ServiceCode: integer; // <----- КОД УСЛУГИ, которую выбрал клиент ...

В БД для статистики хранилось что-то типа:

IDCLIENT | SERVICECODE | ....

Например, чтобы сделать выборку по услугам, сколько клиентов заказывали ту или иную услугу:

SELECT SERVICECODE, Count(*) FROM blabla GROUP BY SERVICECODE

Получилось бы:

Код услуги | Сколько клиентов пользовались этой услугой

а теперь нужно сделать тоже самое, но с учетом того, что клиент может заказать набор услуг. То есть, теперь:

TClientInfo = packed record ServiceCode: TServiceList; ...

и в БД:

IDCLIENT | <Список кодов услуг, на которые подписался клиент> | ....

Так вот что использовать вместо TServiceList и <Список кодов услуг, на которые подписался клиент>.
Или какие другие приемы есть?

P.S. Надеюсь, сейчас то понятно стало...

← →
clickmaker © (2009-01-12 15:20) [21]

> Или какие другие приемы есть?

уже в [4] ответили
clientid | serviceid
таблица-связка

← →
Jeer © (2009-01-12 15:24) [22]

Намешал кислое с пресным :(
Отдели мухи от котлет и будет легче.

Выборка может уточняться предикатом WHERE IN

← →
Добежал (2009-01-12 15:27) [23]

Допустим, clientid это уникальный идентификатор клиента.

Тогда я не понимаю, что такое serviceid? Это некий указатель на перечень услуг? А где тогда "справочник" для этого указателя? Что там будет, все возможные комбинации услуг?!

Можно на примере в числах?

← →
clickmaker © (2009-01-12 15:36) [24]

> А где тогда "справочник" для этого указателя

serviceid | servicename
1 | массаж
2 | тайский массаж
3 | педикюр

← →
Sergey13 © (2009-01-12 15:37) [25]

> [9] Добежал (12.01.09 13:46)
> Клиент может выбрать любое сочетание услуг

Вот и создай таблицу "Выбор клиента" в которой храни все выбранные им коды. Вернее в подчиненной ей таблице "Коды выбранные клиентом", так же заново созданной.

← →
Труп Васи Доброго © (2009-01-12 15:44) [26]

Даскажите вы ему по русски: "теб нужна третья таблица типа "Таблица заказов/накладных" и т.п" где храниться информация именно о заказе, то есть ID заказа, ID клиента, кто это заказал, ID продавца, который обслуживал, ID кладовщика, который доставил и упаковал, и т.д. дата заказа, ID магазина/филиала, где заказали, доп информация и прочая хрень. И нужна ещё одна таблица связка (ID заказа, ID товара/услуги). Теперь понятно???

← →
Jeer © (2009-01-12 15:44) [27]

Как все запущено.. а понтов-то в [0]
В букварь и носом, однозначно.

← →
Jeer © (2009-01-12 15:46) [28]

> Труп Васи Доброго © (12.01.09 15:44) [26]
>
> Даскажите вы ему по русски: "теб нужна третья таблица типа
**
Теперь понятно???

Кому, нам ?
Т.е. ты добрый, такой, транслятор с урюпинского на суахили ?

← →
Добежал (2009-01-12 16:04) [29]

Ты читаешь что пишут? Я тебе уже весь механизм расписал! Высылай гонорар!

> что писать в таблицу:
> clientid | serviceid
> если клиент выбрал тайский массаж и педикюр?
> <Цитата>
>
>

2 записи писать:

ID Васи Пупкина - ID тайского массажа
ID Васи Пупкина - ID педикюра

← →
Добежал (2009-01-12 16:24) [32]

> 2 записи писать:
> ID Васи Пупкина - ID тайского массажа
> ID Васи Пупкина - ID педикюра

понял... Тогда получится, что на каждого клиента как минимум еще одна запись в этой таблице. Хотя в реальности в 99,9% случаев будет выбрана лишь одна услуга. Получится некоторое такое дублирование что ли...

> Получится некоторое такое дублирование что ли

Это самое "дублирование", коротое тебя так смущает, позволит выполнять высокоэффективные запросы любого вида.

> Добежал (12.01.09 16:24) [32]

Быстро читать книжки.
Тебя заботит частота обращения к жесткому диску и как он себя при этом будет чувствовать ?

← →
Добежал (2009-01-12 16:38) [35]

Да, думаю ты абсолютно прав. Просто есть какое-то стремление к экономии, менталитетное стремление к экономии ;)... Была одна таблица, а тут по такому поводу делать аж две ;)))
Спасибо тебе и clickmaker"у за помощь!

← →
Добежал (2009-01-12 16:39) [36]

большое спасчибо я, конечно, выражал Сергею М. и clickmaker"у!

> Была одна таблица, а тут по такому поводу делать аж две

Можно и одной обойтись.
Но тогда прощайся с гибкостью и эффективностью потенциальных запросов к такой базе.

Закон неумолим: выигрываешь в скорости - проигрываешь в ресурсах, выигрываешь в ресурсах - проигрываешь в скорости.

> Была одна таблица, а тут по такому поводу делать аж две
> ;)))

Вот тебе нужно добраться от.. Парижа до Владивостока, к примеру.

Можно, в соответствии с твоими посылами идти пехом - всего-лишь один вариант передвижения. Ну дойдешь..когда-нибудь.
Можно сесть на самолет или даже ракетолет - цена вопроса ?
А можно.. подумать, узнав особенности и цену передвижения разными транспортными средствами и добраться довольно быстро и дешево.

Вот это и есть оптимизация по заданному критерию(ям).
Уверяю тебя, проектировщики баз данных, в основном, применяют именно крайний упомянутый подход.

Т.е. можно теоретически использовать не более 3-4 таблиц, но делают все же не тысячу, а несколько меньше. :)

← →
Дуп (2009-01-12 16:49) [39]

> Добежал (12.01.09 16:39) [36]

Э, а мне и > Правильный$Вася (12.01.09 13:09) [4]

Не жукуй.

> Добежал

Одной таблицей можно обойтись только если тебе не потребуются запросы вида "получить список клиентов, подписанных на такие-то услуги, при условии что полный список возможных услуг заранее неизвестен и может пополняться"

Хранение списка услуг Найти похожие ветки