Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Проблемка с удалением записей из набора данных [IB6.x]

Страницы: 1 2 3 4 >
Juice © (2005-10-05 10:21:00)
Есть TIBDataSet, делаю в него выборку а затем программно удаляю из него множетсво записей, но удаляю имено из набора данных и на саму базу это не отображается - в DeleteSQL стоит что-то наподобие "Delete from ... where 1=2", аналогично и в ModifySQL. После этого показываю это все в TDBGrid.

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

Попробовал разобраться в чем дело, и обнаружил следующее. Это код, который я вставил после функции "удаления ненужных записей" :
First; while not eof do begin Next; end;
В дебагере имеем следующее :
RecorcCount - 33.
RecNo : после First - 7 ! (Почему?)
после первого Next - 9,
после второго Next - 15,
...
после n-ного Next - 45, (что уже больше чем RecordCount!)
и т.п.

Наверное отсюда и все глюки грида (кстати пробовал и другие гриды, проблема явно не в гриде). Может вы что-то подскажите?

Juice (2005-10-11 19:36:00) [1]

> В любом случае, через несколько месяцев на реальных данных
> отгребещь тормоза с постоянным
> пересчетом остатка. А если ты еще весь свой orders на клиент
> будешь утягивать и там считать,
> тормоза наступят намного раньше.
> Знаю я одних, у которых табличка dbf - аналог твоего orders,
> весит за 900 мегабайт, если
> бы , то давно-
> бы разорились, или повесили такого
> милого программера как ты за одно интимное место.

Ну просто телепатические способности и умение предсказывать будущее по ... SQL-запросам ?
А насчет "по-идиотски", я тебе могу с абсолютной увереностью сказать - это не по-идиотски:) А если тебе охота поспорить то могу тебе обьяснить почему так, и сказать даже больше - раньше вся эта фигня считалась на сервере в виде ХП - лажа была страшная.

Juice (2005-10-11 19:24:00) [2]

> Млин, ну шо ты какой сложный? CDS это и есть лишнее телодвижение.
>
> Не хочешь делать в ХП, делай так:

Млин, ну шож ты не читаешь вопроса ? Было бы все так просто а я настолько тупым, то думаю и до тебя другие люди догадались бы написать слово sum. Мне остаток нужен вместе с историейего формирования, понимаешь ? Т.е. я должен знать, что если на дату А товара Б осталось 10 шт., то сколько когда и как он покупался, всю историю этих остатков.

> да, в запросах пиши не
> GROUP BY
> а
> GROUP BY goods_id
> :)

Может подскажешь еще что вместо :REST_DATE писать ? :)

Danilka (2005-10-10 08:59:00) [3]
да, в запросах пиши не
GROUP BY
а
GROUP BY goods_id
:)

Danilka (2005-10-10 08:58:00) [4]
Juice © (07.10.05 18:19)
Все, проблема снята. Через CDS все было очень просто и без лишних телодвижений.

Млин, ну шо ты какой сложный? CDS это и есть лишнее телодвижение.
Не хочешь делать в ХП, делай так:

SELECT good_id, sum(quantity*(sale*2-1)) rest_amount
FROM orders
WHERE date <= :REST_DATE
GROUP BY

Если у тебя не IB6, а FB, то у него есть case, и запрос будет выглядеть так:

SELECT
good_id,
sum(CASE sale WHEN 1 THEN quantity ELSE -quantity END) rest_amount
FROM orders
WHERE date <= :REST_DATE
GROUP BY

Таблица orders;
good_id - код товара
date - дата ввода /вывода;
quantity - кол-во ввода/вывода;
sale - boolean 1- продажа, 0 - покупка;

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

Juice (2005-10-07 18:19:00) [5]
Все, проблема снята. Через CDS все было очень просто и без лишних телодвижений.

Juice (2005-10-07 17:45:00) [6]
К сожалению варианты с модификацией базы не подходят по независимым от меня причинам.

> ЗЫ. А зачем удалять из CDS ? Если туда можно класть только
> нужные записи ?

Дайте пожалуйста какую-то подсказку, не могу разобраться со всеми этими провайдерами

Курдль (2005-10-07 16:41:00) [7]
Приведу максимально упрощенный рабочий запрос из похожей задачи:
select D.DEA_ID, D.DEA_DATE, A.ART_ID, A.ART_CODE, D.DEA_PRI, D.DEA_VOL-isnull( (select sum(BIN_VOL) from BINDINGS B, DEALS S where B.DEA_ID_BUY = D.DEA_ID and B.DEA_ID_SAL = S.DEA_ID and S.DEA_DATE <= :DEA_DATE ),0) as DEA_VOL from DEALS D, ARTICLES I where D.DEA_TYPE = 'BUY' and D.ART_ID = A.ART_ID and DEA_VOL > 0 and D.DEA_DATE <= :DEA_DATE
Где
BINDINGS - связь сделок
DEALS - сделки
ARTICLES - товары

Danilka (2005-10-07 16:32:00) [8]
Juice © (07.10.05 16:16)
На опр. момент нужно получить состояние (остаток). Упростим еще - в таблице содержится инф. про торги только одного товара.
Давайте рассмотрим на конкретном примере:
Таблица orders;
date - дата ввода /вывода;
quantity - кол-во ввода/вывода;
sale - boolean 1- продажа, 0 - покупка;

1. (правильный, незнаю есть-ли он в ИБ6) используя case
2. (извращенный) sum(quantity*(sale*2-1))
3. в ХП

:)
А по-хорошему еще следует хранить остатки в регистре остатков.

Курдль (2005-10-07 16:21:00) [9]
На одной таблице пример не получится.
Я вижу, как минимум - две.
1. Сделки или Ваша orders
2. Связь сделок (bindings)

Последняя должна быть ассоциативно-зависимой от первых 2-х (иметь составной первичный ключ из их ID). Причем - с бизнес условием: "покупке" может быть сопоставлена только "продажа" иколичеством не превышающая покупку.

Juice (2005-10-07 16:16:00) [10]
Вы конечно извините, но можно все-таки по сабжу продолжить ?

> Desdechado © (05.10.05 11:06) [3]
> > Delete from ... where 1=2
> имхо, если ничего не вписывать, ничего и не случится с БД
>
> а с правильным запросом и вопросов не будет, как сказал
> ANB

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

> есть активы (товар), есть сделки (покупка/продажа). Надо
> вычислить портфель (остаток).
> Здесь вообще нечего удалять!

> Курдль © (05.10.05 12:39) [9]
> Надо знать структуру БД.
> Видится приблизительно так
>
> Товары(наименование) +-< Сделки(дата, К/П, кол-во, цена)
>
> Отсюда выполнить необходимый запрос элементарно.

Судя по этим словам для всех авторов этих постов написать нужный запрос не составляет труда и представляется очевиднейшим решением ?
Я например долго думал и ничего не придумал. Может я sql плохо знаю или думалка не работает. Хотелось бы таки услышать ответ, пусть и на простейший пример : таблица это просто стэк - последний пришел - первый ушел. На опр. момент нужно получить состояние (остаток). Упростим еще - в таблице содержится инф. про торги только одного товара.
Давайте рассмотрим на конкретном примере:
Таблица orders;
date - дата ввода /вывода;
quantity - кол-во ввода/вывода;
sale - boolean 1- продажа, 0 - покупка;

Если это так элементарно, то почему бы вам не привести пример ?

Sergey_Masloff (2005-10-07 11:11:00) [11]
Seg (07.10.05 10:58) [53]
Если учесть что это человек профессионально занимающийся аудитом информационных систем корпоративного уровня и именно по этому поводу произошло мое с ним знакомство то позволю себе проигнорировать ваше мнение. Конкретный пример он приводил, я, к сожалению, не могу его процитировать.

Seg (2005-10-07 10:58:00) [12]
для мелких с тенденцией к средним систем Oracle подходит хорошо но выше начинается другая ниша в которой он просто не представлен. Там область для DB2 и... " он назвал еще какие-то две системы но я, к стыду своему, о них не слышал. Человек компетентный хоть и буржуй а считается что все американе дураки.

Это он прочитал в каком-нибудь рекламном проспекте.
Если бы он самолично переполнил данными Оракл, или привел бы конкретный пример, а так, надувать щеки и разводить руками любой может.

Курдль (2005-10-07 10:34:00) [13]

> Sergey_Masloff (06.10.05 20:34) [51]

Снимаю шляпу перед терабайтами! Пока не представляю, куда бы это можно было применить. На этом форуме редко кто заводит речь про системы, выше уровня рабочей группы и еще ведутся споры об успешном применении Paradox и FoxPro. Ни разу не слышал, чтобы хоть раз кто-то пожаловался, что он уперся в возможности оракла. Но у нас все возможно. Знаю, что одна фирма делала билинговую систему на MS SQL. И даже продала ее, несмотря на то, что цикл расчета мог длиться 3-е суток. (Типа: "купите себе хорошее железо!")

Мне пока не представлялась возможность автоматизировать предприятия одного уровня с NASA и Пентагоном, которые не жалуются на оракл.

Но если придется - обязательно изучу возможности DB2 Informix и т.п.

Sergey_Masloff (2005-10-06 20:34:00) [14]
Курдль © (06.10.05 15:00) [46]
>> IBM DB2 к примеру.

>Много хорошего слышал про ее производительность, но сам поработать >чести не имел.

Я видел только "персонал" версию которая от "той" DB2 отличается сильно. Просто слышал мнение примерно такое "для мелких с тенденцией к средним систем Oracle подходит хорошо но выше начинается другая ниша в которой он просто не представлен. Там область для DB2 и... " он назвал еще какие-то две системы но я, к стыду своему, о них не слышал. Человек компетентный хоть и буржуй а считается что все американе дураки. Но это не так. Кстати наша система (мы в своей области ну в тройку в России точно входим да и в европе наверное не затеряемся) по их классификации именно "маленькая система". Я не готов назвать параметры системы (конфиденциальная информация) но поверь она немаленькая. Мне кажется что средней считалась бы база минимум несколько терабайт и числом пользователей в десятки тысяч. Это просто мое предположение, я лично не уточнял.

Seg (2005-10-06 16:50:00) [15]
На самом деле существуют специальные оценочные таблицы и методики.

Вот и примени эти методики, потом результат покажешь.

Курдль (2005-10-06 16:44:00) [16]

> Seg (06.10.05 16:30) [47]
> Что вы подразумеваете под производительностью?
> скорость выполнения запросов?

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

На самом деле существуют специальные оценочные таблицы и методики.

Anatoly Podgoretsky (2005-10-06 16:35:00) [17]
Seg (06.10.05 14:36) [44]
Разве это количество MSSQL поддерживает 1000000 террабайт базы. Оракл тоже как минимум такого порядка, про DB2 вообще молчу. Среди моих знакомых есть люди у которых свыше 8 000 000 000 записей в таблице, даже не в базе.

Seg (2005-10-06 16:30:00) [18]
Что вы подразумеваете под производительностью?
скорость выполнения запросов?

Курдль (2005-10-06 15:00:00) [19]

> Sergey_Masloff (06.10.05 14:51) [45]
> IBM DB2 к примеру.

Много хорошего слышал про ее производительность, но сам поработать чести не имел.
А как она в проектировании? Чем отличается от оракла?

Я как-то загорелся идеей FastObjects от Versant. Даже скачал демо-версию и интегрировал в среду. Потыкал наугад - работает.
Но ни времени потестировать, ни подходящих проектов для экспериментов не выдалось. Потом надежные источники порекомендовали забить на эти попытки.

Sergey_Masloff (2005-10-06 14:51:00) [20]
Курдль © (06.10.05 14:19) [43]
IBM DB2 к примеру. Или в мире только 2 SQL сервера осталось?

Seg (06.10.05 14:36) [44]
>Я работал с базой Оракл с количеством записей 145 миллионов
И что? с десятками млн. я работал и в InterBase ;-)
В оракле я их и не считаю. Больше 145 млн. это 100% но все это не показатель.

Страницы: 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »