Форум: "Прочее";
Текущий архив: 2009.03.15;
Скачать: [xml.tar.bz2];
ВнизХранение списка услуг Найти похожие ветки
← →
Добежал (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]
> serviceid | servicename
> 1 | массаж
> 2 | тайский массаж
> 3 | педикюр
ок, и что писать в таблицу:clientid | serviceid
если клиент выбрал тайский массаж и педикюр?
← →
Труп Васи Доброго © (2009-01-12 16:08) [30]Ты читаешь что пишут? Я тебе уже весь механизм расписал! Высылай гонорар!
← →
Сергей М. © (2009-01-12 16:08) [31]
> что писать в таблицу:
> clientid | serviceid
> если клиент выбрал тайский массаж и педикюр?
> <Цитата>
>
>
2 записи писать:
ID Васи Пупкина - ID тайского массажа
ID Васи Пупкина - ID педикюра
← →
Добежал (2009-01-12 16:24) [32]
> 2 записи писать:
> ID Васи Пупкина - ID тайского массажа
> ID Васи Пупкина - ID педикюра
понял... Тогда получится, что на каждого клиента как минимум еще одна запись в этой таблице. Хотя в реальности в 99,9% случаев будет выбрана лишь одна услуга. Получится некоторое такое дублирование что ли...
← →
Сергей М. © (2009-01-12 16:28) [33]
> Получится некоторое такое дублирование что ли
Это самое "дублирование", коротое тебя так смущает, позволит выполнять высокоэффективные запросы любого вида.
← →
Jeer © (2009-01-12 16:35) [34]
> Добежал (12.01.09 16:24) [32]
Быстро читать книжки.
Тебя заботит частота обращения к жесткому диску и как он себя при этом будет чувствовать ?
← →
Добежал (2009-01-12 16:38) [35]Да, думаю ты абсолютно прав. Просто есть какое-то стремление к экономии, менталитетное стремление к экономии ;)... Была одна таблица, а тут по такому поводу делать аж две ;)))
Спасибо тебе и clickmaker"у за помощь!
← →
Добежал (2009-01-12 16:39) [36]большое спасчибо я, конечно, выражал Сергею М. и clickmaker"у!
← →
Сергей М. © (2009-01-12 16:42) [37]
> Была одна таблица, а тут по такому поводу делать аж две
Можно и одной обойтись.
Но тогда прощайся с гибкостью и эффективностью потенциальных запросов к такой базе.
Закон неумолим: выигрываешь в скорости - проигрываешь в ресурсах, выигрываешь в ресурсах - проигрываешь в скорости.
← →
Jeer © (2009-01-12 16:45) [38]
> Была одна таблица, а тут по такому поводу делать аж две
> ;)))
Вот тебе нужно добраться от.. Парижа до Владивостока, к примеру.
Можно, в соответствии с твоими посылами идти пехом - всего-лишь один вариант передвижения. Ну дойдешь..когда-нибудь.
Можно сесть на самолет или даже ракетолет - цена вопроса ?
А можно.. подумать, узнав особенности и цену передвижения разными транспортными средствами и добраться довольно быстро и дешево.
Вот это и есть оптимизация по заданному критерию(ям).
Уверяю тебя, проектировщики баз данных, в основном, применяют именно крайний упомянутый подход.
Т.е. можно теоретически использовать не более 3-4 таблиц, но делают все же не тысячу, а несколько меньше. :)
← →
Дуп (2009-01-12 16:49) [39]> Добежал (12.01.09 16:39) [36]
Э, а мне и > Правильный$Вася (12.01.09 13:09) [4]
Не жукуй.
← →
Сергей М. © (2009-01-12 16:57) [40]
> Добежал
Одной таблицей можно обойтись только если тебе не потребуются запросы вида "получить список клиентов, подписанных на такие-то услуги, при условии что полный список возможных услуг заранее неизвестен и может пополняться"
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2009.03.15;
Скачать: [xml.tar.bz2];
Память: 0.55 MB
Время: 0.043 c