Проблемка с удалением записей из набора данных

← →
Курдль © (2005-10-06 14:08) [40]

> Sergey_Masloff (06.10.05 12:10) [38]
> А по производительности и объемам у оракла конкуренты имеются, не сомневайся.

Не сомневаюсь, а абсолютно уверен, что по производительности и объемам у оракла конкуренты отсутствуют. За это и денежки платят, а не за connect ... by prior ...

← →
Sergey_Masloff (2005-10-06 14:14) [41]

Курдль © (06.10.05 14:08) [40]
>Не сомневаюсь, а абсолютно уверен, что по производительности и объемам >у оракла конкуренты отсутствуют
На сем позвольте откланяться. У меня сведения другие но полемезировать на эту тему не собираюсь.

← →
Anatoly Podgoretsky © (2005-10-06 14:16) [42]

Курдля не трогать, а то потеряем такого ценного кадра.

← →
Курдль © (2005-10-06 14:19) [43]

> Sergey_Masloff (06.10.05 14:14) [41]
> На сем позвольте откланяться. У меня сведения другие но
> полемезировать на эту тему не собираюсь.

Очень прошу сообщить такие данные. Мы, конечно, любим здесь поспорить, иногда даже не в тему, но все равно приходим сюда за знаниями! Не затруднит поделиться, кто это составил конкуренцию ораклу? MS SQL 2005 Yukon?

← →
Seg (2005-10-06 14:36) [44]

Я работал с базой Оракл с количеством записей 145 миллионов.
Мне смешно смотреть, как люди делают круглые глаза, говоря, что в их базе 100 тысяч записей...

← →
Sergey_Masloff (2005-10-06 14:51) [45]

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

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

← →
Курдль © (2005-10-06 15:00) [46]

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

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

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

← →
Seg (2005-10-06 16:30) [47]

Что вы подразумеваете под производительностью?
скорость выполнения запросов?

← →
Anatoly Podgoretsky © (2005-10-06 16:35) [48]

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

← →
Курдль © (2005-10-06 16:44) [49]

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

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

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

← →
Seg (2005-10-06 16:50) [50]

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

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

← →
Sergey_Masloff (2005-10-06 20:34) [51]

Курдль © (06.10.05 15:00) [46]
>> IBM DB2 к примеру.

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

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

← →
Курдль © (2005-10-07 10:34) [52]

> Sergey_Masloff (06.10.05 20:34) [51]

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

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

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

← →
Seg (2005-10-07 10:58) [53]

для мелких с тенденцией к средним систем Oracle подходит хорошо но выше начинается другая ниша в которой он просто не представлен. Там область для DB2 и... " он назвал еще какие-то две системы но я, к стыду своему, о них не слышал. Человек компетентный хоть и буржуй а считается что все американе дураки.

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

← →
Sergey_Masloff (2005-10-07 11:11) [54]

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

← →
Juice © (2005-10-07 16:16) [55]

Вы конечно извините, но можно все-таки по сабжу продолжить ?

> 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 - покупка;

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

← →
Курдль © (2005-10-07 16:21) [56]

На одной таблице пример не получится.
Я вижу, как минимум - две.
1. Сделки или Ваша orders
2. Связь сделок (bindings)

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

← →
Danilka © (2005-10-07 16:32) [57]

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

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

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

Приведу максимально упрощенный рабочий запрос из похожей задачи:
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 - товары

К сожалению варианты с модификацией базы не подходят по независимым от меня причинам.

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

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

Все, проблема снята. Через CDS все было очень просто и без лишних телодвижений.

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 мегабайт, если
бы они считали остаток также по-идотски как и ты, то давно-бы разорились, или повесили такого
милого программера как ты за одно интимное место.

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

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

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

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

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

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

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

Проблемка с удалением записей из набора данных Найти похожие ветки