powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Оптимизация Таблицы
17 сообщений из 17, страница 1 из 1
Оптимизация Таблицы
    #32390531
Проблема: разрослась таблица. Очень много повторяющихся записей, отличающихся друг от друга одним параметром (ну к примеру суммой). Т.е при группировке таблица была б меньше.
Может кто решал такую проблему ? Образцы кода не прошу. Опишите, плиз, принцип: как это лучше и быстрее сделать ?
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32390537
Фотография Johnmen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> как это лучше и быстрее сделать ?

Что именно ?
Что предполагается оптимизировать ?
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32390550
Поясняю: хочу сжать таблицу. Чтоб вместо миллиона записей физически хранилось полмиллиона. Вот процедура для этого и нужна.
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32390572
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почитай теорию, в частности о нормальных формах. Ищи поисковиком - по этому масса статей.
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32390601
Фотография Johnmen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Чтоб вместо миллиона записей физически хранилось полмиллиона

При той же полноте информации ? Это нормализация. См. Gold
Или нет ? Тогда удали поллимона...И все дела...:) Ну там ещё backup/restore может быть...
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32391749
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Johnmen
Тогда удали поллимона...И все дела...:)
Предлагаю не ограничиваться полумерами. Надо весь мильён грохнуть. 8-)

2ХакунаМатата
Поясняю: хочу сжать таблицу
Возми архиватор и сожми. 8-)

Серьезно:
ИМХО, тут не таблицу надо оптимизировать, а в консерватории править...

Очень много повторяющихся записей, отличающихся друг от друга одним параметром (ну к примеру суммой).

Расшифруй. Как это? Если такое недопустимо, то как такие записи оказываются в таблице? Если их наличие оправдано логикой работы, то зачем их выбрасывать?
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32391945
Серега, объясняю как возникают дубликаты.
Существует авансовое финансирование, т.е. деньги пересылаются за еще не оказанные услуги. Причем для простоты экономического учета пересылают круглыми суммами(100 000, 200 000, 56 000 и т.д.). Впоследствии эти платежи закрываются реальными счетами за реально оказанные услуги. Счета могут быть разношерстные: хоть 100 счетов по 1000 руб., хоть два счета по 50 000.
Т.о. иногда возникают ситации когда надо запись платежа раздробить: например 100 000 = 44000+33000+23000. Вполне реальная ситуация. Еще практикуется иногда изменение назначения платежа, т.е. волевым решением отменяется оплата прежних счетов, а под эти платежи подкладываются совершенно другие счета за другие услуги. Вот так на протяжении 10 лет сбора и анализа информации все разбивалось и дробилось.
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32392004
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2ХакунаМатата
Все равно не понятно ничего. 8-(
Какая структура у таблиц? У записей есть признаки, что они авансовые платежи или окончательные счета? Платежи и счета в одной таблице? Они ссылаются на какой то порождающий их документ (договор какой нить или еще чего)? Ты хочешь авансовые грохнуть? Или как?
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32392013
kata
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Можно строить приложения баз данных по принципу одна база - одна таблица, и сваливать в эту таблицу всё как в помойное ведро ;)

В одной таблице должны храниться данные одной сущности. У вас должно быть две таблицы. В первой хранятся данные авансовых платежей. Во второй - данные оказанных услуг. Авансовый платеж может быть в зачет нескольких услуг. Услуга может быть оказана в счет нескольких платежей. Отношение между таблицами - много на много. Оно реализуется через третью таблицу.
Она состоит из полей: ID записи из первой таблицы, ID записи из второй таблицы, частичная сумма.

При этом если объединить первую и третью таблицы, то можно узнать для каждого авансового платежа сколько ещё осталось погасить услугами, а также ссылки на те услуги, которые этот платеж закрывает.
А если объединить вторую и третью таблицу, то можно для каждой услуги узнать на сколько услуга оплачена и какими платежами.
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32392081
Пример: Исходная ситуация
Счета Платежи

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

Вот маленькая модель как все это реализовывалось.
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32392096
Так я думаю понятней будет

Таблица "счета"

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
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32392438
Фотография Bol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bol - Вчитайся в то, что уже сказали:
авторВ одной таблице должны храниться данные одной сущности. У вас должно быть две таблицы. В первой хранятся данные авансовых платежей. Во второй - данные оказанных услуг. Авансовый платеж может быть в зачет нескольких услуг. Услуга может быть оказана в счет нескольких платежей. Отношение между таблицами - много на много. Оно реализуется через третью таблицу.
Она состоит из полей: ID записи из первой таблицы, ID записи из второй таблицы, частичная сумма.
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32392889
__гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
народ, кончайте человеку мозги парить!
здесть проблема совсем в другом - нужны ли ему данные десятилетней
давности?
насколько я помню, период надоговой отчетности состваляет что-то
около 3-х лет, так что все более старое можно спокойно удалять,
проверив в бухгалтерии, насколько я прав
а чтобы не потерять взаиморасчеты по дебиторам/кредиторам,
наваять отдельную маленькую табличку с остатками на начало периода
и рассчитать ее перед удалением
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32392917
IgorL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
при группировке таблица стала бы меньше...

ИМХО ответ в вопросе.
Сгруппировать, а что за пределами группы удалить нафиг. :)

К сожалению без ХП скорей всего не обойтись, но это с другой стороны и плюс.
Заряди шедулер в него простенького клиента, запускающего твою ХП ночью.
Утром будешь иметь пожатую базу.

Код типа :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Переменные...
For Select совпадающие_столбцы from твоя_табличка
group by совпадающие_столбцы
hawing Count (совпадающий_столбец) >  1 
into 
do Переменные...
 Delete from твоя_табличка
  begin
   where совпадающий_столбец1 <> Переменная1 and
           совпадающий_столбец2 <> Переменная2...
  end


Нормализацию же, ИМХО, не всегда стоить ставить превыше удобства работы и понятности базы.
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32392919
IgorL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сорри.
Глупость написал. О своем думал. ;)

Две ХП надо.
В первой нужно просуммировать по group by и вставить в эту же табличку,
Во второй удалять группированные записи, не удовлетворяющие условию MAX.
Сумма будет всегда больше отдельновзятого.
Так и объединятся...
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32393061
Спасибо всем !
Особенно за три последние реплики.
Проблема ИМЕННО в ЭТОМ заключалась.
Вопрос к IgorL: говоришь "запусти на ночь, утром получишь.."
Процедуру я написал, и она отработала, но процесс действительно долгий(измеряется часами. Брал тестовый пример и результаты работы спроецировал на реальную таблицу).
Это нормально для миллиона записей, или неоптимально процедура написана ?
...
Рейтинг: 0 / 0
Оптимизация Таблицы
    #32394297
IgorL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сложный вопрос.
План смотреть надо.
Ну процедуры такого рода всегда будут выполнятся долго.
Представь - у тебя лимон записей - после группировки будет допустим пол-лимона, и ты ещё вставишь пол лимона. В итоге вторая процедура будет работать с полторами миллионами рекордов %)
Радует то, что такая хреновая ситуевина будет только один раз - первый.
Потом легче :)
У меня самого была подобная задача, правда в другой СУБД....
Но записей там было даже больше.
Тут вот еще какая проблема - если первая или вторая процедура прервется - ты таблицу поломаешь! Сумма станет непресказуемой! То же случится, если процедурки не успеют отработать...
Я перебрал несколько вариантов:
Группировал, суммировал и вставлял две записи - сумму и её же но с минусом.
В результате убивалось два зайца - сумма по критериям не менялась в любой момент, и наличие в таблице отрицательных чисел было признаком аварии.
М все равно было несколько беспокойно :)

В конце концов базу я процедурку затолкал в триггер на инсерт и апдейт, то есть делая группировку (а там получается вовсе даже не группировка, Select обычный ) и вставляя сразу сумму, убивая её составляющие.
...
Рейтинг: 0 / 0
17 сообщений из 17, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Оптимизация Таблицы
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]