|
|
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Проблема: разрослась таблица. Очень много повторяющихся записей, отличающихся друг от друга одним параметром (ну к примеру суммой). Т.е при группировке таблица была б меньше. Может кто решал такую проблему ? Образцы кода не прошу. Опишите, плиз, принцип: как это лучше и быстрее сделать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2004, 12:50 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
> как это лучше и быстрее сделать ? Что именно ? Что предполагается оптимизировать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2004, 12:51 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Поясняю: хочу сжать таблицу. Чтоб вместо миллиона записей физически хранилось полмиллиона. Вот процедура для этого и нужна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2004, 12:56 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Почитай теорию, в частности о нормальных формах. Ищи поисковиком - по этому масса статей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2004, 13:05 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
>Чтоб вместо миллиона записей физически хранилось полмиллиона При той же полноте информации ? Это нормализация. См. Gold Или нет ? Тогда удали поллимона...И все дела...:) Ну там ещё backup/restore может быть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2004, 13:18 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
2Johnmen Тогда удали поллимона...И все дела...:) Предлагаю не ограничиваться полумерами. Надо весь мильён грохнуть. 8-) 2ХакунаМатата Поясняю: хочу сжать таблицу Возми архиватор и сожми. 8-) Серьезно: ИМХО, тут не таблицу надо оптимизировать, а в консерватории править... Очень много повторяющихся записей, отличающихся друг от друга одним параметром (ну к примеру суммой). Расшифруй. Как это? Если такое недопустимо, то как такие записи оказываются в таблице? Если их наличие оправдано логикой работы, то зачем их выбрасывать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 09:01 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Серега, объясняю как возникают дубликаты. Существует авансовое финансирование, т.е. деньги пересылаются за еще не оказанные услуги. Причем для простоты экономического учета пересылают круглыми суммами(100 000, 200 000, 56 000 и т.д.). Впоследствии эти платежи закрываются реальными счетами за реально оказанные услуги. Счета могут быть разношерстные: хоть 100 счетов по 1000 руб., хоть два счета по 50 000. Т.о. иногда возникают ситации когда надо запись платежа раздробить: например 100 000 = 44000+33000+23000. Вполне реальная ситуация. Еще практикуется иногда изменение назначения платежа, т.е. волевым решением отменяется оплата прежних счетов, а под эти платежи подкладываются совершенно другие счета за другие услуги. Вот так на протяжении 10 лет сбора и анализа информации все разбивалось и дробилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 11:00 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
2ХакунаМатата Все равно не понятно ничего. 8-( Какая структура у таблиц? У записей есть признаки, что они авансовые платежи или окончательные счета? Платежи и счета в одной таблице? Они ссылаются на какой то порождающий их документ (договор какой нить или еще чего)? Ты хочешь авансовые грохнуть? Или как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 11:24 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Можно строить приложения баз данных по принципу одна база - одна таблица, и сваливать в эту таблицу всё как в помойное ведро ;) В одной таблице должны храниться данные одной сущности. У вас должно быть две таблицы. В первой хранятся данные авансовых платежей. Во второй - данные оказанных услуг. Авансовый платеж может быть в зачет нескольких услуг. Услуга может быть оказана в счет нескольких платежей. Отношение между таблицами - много на много. Оно реализуется через третью таблицу. Она состоит из полей: ID записи из первой таблицы, ID записи из второй таблицы, частичная сумма. При этом если объединить первую и третью таблицы, то можно узнать для каждого авансового платежа сколько ещё осталось погасить услугами, а также ссылки на те услуги, которые этот платеж закрывает. А если объединить вторую и третью таблицу, то можно для каждой услуги узнать на сколько услуга оплачена и какими платежами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 11:27 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Пример: Исходная ситуация Счета Платежи n №Сч Сумма Платеж n Сумма (Ссылка) 1 1 50 1 1 50 2 2 10 2 2 100 3 3 40 2 3 100 4 3 50 2 4 300 5 3 10 3 6 4 30 3 7 4 60 3 Приходят экономисты и заявляют: "Мы переиграли назначение платежа, Нам выгоднее по-другому" Результат "По-другому" n Счет Сумма Платеж 1 1 50 4 2 2 10 4 3 3 40 4 4 3 50 4 5 3 10 4 6 4 30 4 7 4 60 4 Вот маленькая модель как все это реализовывалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 11:50 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Так я думаю понятней будет Таблица "счета" n___ №Сч_Сумма_Платеж -----------------(Ссылка) 1_____ 1__ 50_____ 1 2_____ 2__ 10_____ 2 3_____ 3__ 40_____ 2 4_____ 3__ 50_____ 2 5_____ 3__ 10_____ 3 6_____ 4__ 30_____ 3 7_____ 4__ 60_____ 3 Таблица Платежи n ___________Сумма 1 ____________50 2____________ 100 3 ____________100 4 ____________300 Результат "По-другому" n Счет Сумма Платеж 1__ 1___ 50____ 4 2__ 2___ 10____ 4 3__ 3___ 40____ 4 4__ 3___ 50____ 4 5__ 3___ 10____ 4 6__ 4___ 30____ 4 7__ 4___ 60____ 4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 11:56 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Bol - Вчитайся в то, что уже сказали: авторВ одной таблице должны храниться данные одной сущности. У вас должно быть две таблицы. В первой хранятся данные авансовых платежей. Во второй - данные оказанных услуг. Авансовый платеж может быть в зачет нескольких услуг. Услуга может быть оказана в счет нескольких платежей. Отношение между таблицами - много на много. Оно реализуется через третью таблицу. Она состоит из полей: ID записи из первой таблицы, ID записи из второй таблицы, частичная сумма. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 14:55 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
народ, кончайте человеку мозги парить! здесть проблема совсем в другом - нужны ли ему данные десятилетней давности? насколько я помню, период надоговой отчетности состваляет что-то около 3-х лет, так что все более старое можно спокойно удалять, проверив в бухгалтерии, насколько я прав а чтобы не потерять взаиморасчеты по дебиторам/кредиторам, наваять отдельную маленькую табличку с остатками на начало периода и рассчитать ее перед удалением ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 20:32 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
при группировке таблица стала бы меньше... ИМХО ответ в вопросе. Сгруппировать, а что за пределами группы удалить нафиг. :) К сожалению без ХП скорей всего не обойтись, но это с другой стороны и плюс. Заряди шедулер в него простенького клиента, запускающего твою ХП ночью. Утром будешь иметь пожатую базу. Код типа : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Нормализацию же, ИМХО, не всегда стоить ставить превыше удобства работы и понятности базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 22:09 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Сорри. Глупость написал. О своем думал. ;) Две ХП надо. В первой нужно просуммировать по group by и вставить в эту же табличку, Во второй удалять группированные записи, не удовлетворяющие условию MAX. Сумма будет всегда больше отдельновзятого. Так и объединятся... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2004, 22:16 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Спасибо всем ! Особенно за три последние реплики. Проблема ИМЕННО в ЭТОМ заключалась. Вопрос к IgorL: говоришь "запусти на ночь, утром получишь.." Процедуру я написал, и она отработала, но процесс действительно долгий(измеряется часами. Брал тестовый пример и результаты работы спроецировал на реальную таблицу). Это нормально для миллиона записей, или неоптимально процедура написана ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 09:02 |
|
||
|
Оптимизация Таблицы
|
|||
|---|---|---|---|
|
#18+
Сложный вопрос. План смотреть надо. Ну процедуры такого рода всегда будут выполнятся долго. Представь - у тебя лимон записей - после группировки будет допустим пол-лимона, и ты ещё вставишь пол лимона. В итоге вторая процедура будет работать с полторами миллионами рекордов %) Радует то, что такая хреновая ситуевина будет только один раз - первый. Потом легче :) У меня самого была подобная задача, правда в другой СУБД.... Но записей там было даже больше. Тут вот еще какая проблема - если первая или вторая процедура прервется - ты таблицу поломаешь! Сумма станет непресказуемой! То же случится, если процедурки не успеют отработать... Я перебрал несколько вариантов: Группировал, суммировал и вставлял две записи - сумму и её же но с минусом. В результате убивалось два зайца - сумма по критериям не менялась в любой момент, и наличие в таблице отрицательных чисел было признаком аварии. М все равно было несколько беспокойно :) В конце концов базу я процедурку затолкал в триггер на инсерт и апдейт, то есть делая группировку (а там получается вовсе даже не группировка, Select обычный ) и вставляя сразу сумму, убивая её составляющие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2004, 21:44 |
|
||
|
|

start [/forum/topic.php?fid=40&fpage=488&tid=1579293]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 380ms |

| 0 / 0 |
