|
|
|
Поштучно или по диапазонам?
|
|||
|---|---|---|---|
|
#18+
Есть билеты каждый билет имеет свой номер. Билеты упакованныв пачки. Пачки упакованны в Коробки. Вообщем получается дерево. Для этого дерева можно сделать таблицу. Код: plaintext В данной ситуации из-за огромного количества билетов получаеются огромные таблицы. И при перемещении этих билетов также получаться огромные таблицы. Но написать сам фунционал довльно таки просто. Есть другой вариант. хранить билеты диапазонами. Код: plaintext Хранение более удобное, но вот проблема пачки могут вскрываться и разрезаться. Из-за этого фунционал для перемещения билетов сложный. Какой вариант на ваш взгляд лудше применить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 09:45 |
|
||
|
Поштучно или по диапазонам?
|
|||
|---|---|---|---|
|
#18+
Ведем учет бланков строгой отчетности. На складе - учитываем диапазонами (одна табл.), использованные/выданные - поштучно (вторая табл.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 12:57 |
|
||
|
Поштучно или по диапазонам?
|
|||
|---|---|---|---|
|
#18+
Думаю что лучше хранить в одной таблице. В таблицу надо добавить индексы, учитывая, что в таблице 3 поля, всего можно сделать индексы по (box) (pack) (No) (box pack) ( box no) (pack box) (pack no) (no box) (no pack) (box pack no) (box no pack) (pack box no) (pack no box) (no box pack) (no pack box), итого 15 индексов, и какой бы вы не использовали запрос, будет выполнятся поиск по индексу вместо full scan. Если же самому разбивать таблицу на несколько только потому, что она очень большая, то фактически вы пытаетесь решать ту задачу, для которой предназначен sql-сервер, вместо него самого. Вряд ли это получится лучше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 13:11 |
|
||
|
Поштучно или по диапазонам?
|
|||
|---|---|---|---|
|
#18+
olzhasЕсть билеты каждый билет имеет свой номер. Билеты упакованныв пачки. Пачки упакованны в Коробки. Вообщем получается дерево. Для этого дерева можно сделать таблицу. Код: plaintext В данной ситуации из-за огромного количества билетов получаеются огромные таблицы. И при перемещении этих билетов также получаться огромные таблицы. Но написать сам фунционал довльно таки просто. Есть другой вариант. хранить билеты диапазонами. Код: plaintext Хранение более удобное, но вот проблема пачки могут вскрываться и разрезаться. Из-за этого фунционал для перемещения билетов сложный. Какой вариант на ваш взгляд лудше применить? Пока с каждым конкретным билетом не связаны никакие факты, лучше оперировать коробками, пачками с диапазонами №№. При переходе от оптовых операций (работаем с целыми коробками) к мелкооптовым (работаем с целыми пачками) и наконец к розничным (пачку вскрыли, билеты уже не находятся в пачке, распределяются поштучно), можно сгенерировать сначала для каждой коробки, потом пачки и наконец для каждого билета в диапазоне отдельную запись в БД. Когда коробка или пачка вскрывается, она по сути перестаёт существовать как объект учёта. Таблица может быть такой. ID объекта. Тип объекта: коробка, пачка, <может быть промежуточные уровни>, билет. Первый номер в диапазоне. Последний номер в диапазоне. (У билета первый и последний момера совпадают). Ссылка на ID Коробки. Ссылка на ID Пачки. Ссылка на ID Объекта промежуточного уровня. Вместо введения поля "Тип объекта" можно создать отдельные таблицы для объектов каждого типа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 15:16 |
|
||
|
Поштучно или по диапазонам?
|
|||
|---|---|---|---|
|
#18+
2 mcureenab Сделал почти по вашему совету. создал таблицу tTicketRange Код: plaintext Сделал таблицы меремещения (Master-details) tMoveHead Код: plaintext tMoveTable Код: plaintext Если перемещается коробка то испольщуем все диапазоны этой коробки Если используется пачка то используется один диапазон (т.е. idTicketRange) Если пачка вскрывается то запускаем процедуру разрезания пачки которая вставляет в tTicketRange 3 Сточки Пример когда в пачку 1-1000, режим от 200 до 599 Код: plaintext 1. 2. 3. 4. По ParentPack можно узнать разрывалась пачка или нет. Как вам такой вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 08:44 |
|
||
|
Поштучно или по диапазонам?
|
|||
|---|---|---|---|
|
#18+
Пользуйтесь поиском, здесь уже не один раз обсуждались проблемы учета по диапазонам. Кратко повторю свое мнение, хранить номера в БД необходимо только поштучно. Вносить первичку и выдавать отчетность по диапазонами, т.е. раскрывать/схлопывать штучный учет в диапазоны. Из собственного опыта все попытки написать "алгебру" для работы с диапазонами к хорошему результату не приводят. Вы просто не столкнулись еще со всеми проблемами такого учета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2007, 13:04 |
|
||
|
Поштучно или по диапазонам?
|
|||
|---|---|---|---|
|
#18+
EstetsПользуйтесь поиском, здесь уже не один раз обсуждались проблемы учета по диапазонам. Любое решение будет иметь недостатки. Нужно сравнивать проблемы того и другого подхода. Ведь на бумаге никто не составляет список всех серийных №№ билетов в пачке, так зачем это делать в электронной БД? Собственно в решении предлагается комбинированный подход. Когда с диапазонами возникают реальные сложности, при том что выгода становится незначительной, мы переходим к штучному учёту. EstetsИз собственного опыта все попытки написать "алгебру" для работы с диапазонами к хорошему результату не приводят. Видимо плохо писали. Задача конечно нетривиальная но в определённых случаях вполне решаемая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2007, 14:04 |
|
||
|
Поштучно или по диапазонам?
|
|||
|---|---|---|---|
|
#18+
mcureenab Любое решение будет иметь недостатки. Нужно сравнивать проблемы того и другого подхода. Ведь на бумаге никто не составляет список всех серийных №№ билетов в пачке, так зачем это делать в электронной БД? Собственно в решении предлагается комбинированный подход. Когда с диапазонами возникают реальные сложности, при том что выгода становится незначительной, мы переходим к штучному учёту. Все написанное ИМХО. olzhas попросил совета "их есть у меня". Проблема "огромного количества билетов - огромные таблицы" на мой взгляд решается просто докупанием еще одного гига памяти серверу БД (100$). А вот проблема проектирования, написания и отладки механизма работы с диапазонами, не решается так просто. У нас в конторе это заняло примерно три человеко-месяца, примерно = 3000$ (3000$ х 3, если учитывать накладные расходы). mcureenab EstetsИз собственного опыта все попытки написать "алгебру" для работы с диапазонами к хорошему результату не приводят. Видимо плохо писали. Задача конечно нетривиальная но в определённых случаях вполне решаемая. Я не сказал, что ее невозможно решить, при разработке было реализовано три алгоритма обработки таких данных. Первые два опирались на работу с диапазонами в разных вариантах, но не усторили заказчика, в одном случае невозможно было получить остатки номеров на дату отличную от текущей и провести операцию "задним числом", в другом случае не устроила производительность, в результате пришлось раелизовывать третий вариант развертывая диапазоны в штуки (две человеко-недели = 500$). ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2007, 10:24 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=34323567&tid=1544732]: |
0ms |
get settings: |
5ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
139ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 426ms |
| 0 / 0 |
