Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 58 59 60 61 62 [63] 64 65 66 67 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Валерий Долженко (aka iscrafm)
SergSuper
и чё? что эти простыни доказывают?

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

Или определить некую функцию возвращающую first-previous-next-last.
4 дек 06, 19:20    [3489724]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
8|
Guest
почему-то в голову лезут странные задачи. имеется алгоритм + ключ шифрования и текущее состояние. применяя ключ + алгоритм на состоянии, извлекаем из него новый ключ + алгоритм и следующее состояние...
интересно, не слишком ли жмет Когаловскому структура его ресурсов.
4 дек 06, 21:26    [3489976]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Валерий Долженко (aka iscrafm)
c127
3. SELECT ... WHERE ... - получает нужную запись
4. Что-то делает с конкретной запись (UPDATE ... WHERE ...)
5. Повторяет пункт 3,4 при необходимости

Ну и в чем разница?

что Вы будете писать в условии WHERE, чтобы получить следующую запись?
в приведенном примере выполняется обработка файла потребностей с ключем Product,Period... Вы запросили при помощи select конкретную запись из этого набора.. что указали в WHERE?.. А потом запрашиваете следующую... по тому же продукту, только следующий период.. что опять пишите в условии WHERE?

Сами же и ответили, в WHERE в каком-то виде я впишу следующий период.

А еще могу создать временную таблицу W и туда добавлять первичные ключи записей, которые обработаны, а в WHERE добавить кроме всего прочего "not in (select * from W)". Нечто похожее Вам тут уже говорили.

Не приведете Вы задачу, не решаемую с помощью запросов ("Есть задачи, которые не решаются при помощи запросов" (С) iscrafm), еще раз повторяю, это строгая математическая теорема. Почитали бы теорию, не тратили бы даром силы на попытки доказать невозможное. Признайте, что Вы ошиблись.

Валерий Долженко (aka iscrafm)

чтобы перемещаться по списку, нужно сначала поиметь этот список.

Список в РСУБД есть всегда, это тоже строгая математическая теорема, она тут неоднократно обсуждалась, этот список может быть перебран элемент за элементом с помощью СКЛ запросов без всяких курсоров.
4 дек 06, 23:35    [3490201]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
8|
почему-то в голову лезут странные задачи. имеется алгоритм + ключ шифрования и текущее состояние. применяя ключ + алгоритм на состоянии, извлекаем из него новый ключ + алгоритм и следующее состояние...
интересно, не слишком ли жмет Когаловскому структура его ресурсов.

Не вижу причин почему нельзя такую задачу решить на оракле. Реализуем алгоритм шифрования на PL/SQL в виде вызываемой из запроса функции. Дальше пишем запрос с inline view и connect by ... во внешнем запросе. Принципиальных проблем я здесь не вижу.
4 дек 06, 23:36    [3490206]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Валерий Долженко (aka iscrafm)
Guest
c127
Валерий Долженко (aka iscrafm)
что Вы будете писать в условии WHERE, чтобы получить следующую запись?

Сами же и ответили, в WHERE в каком-то виде я впишу следующий период.

Какой из перечисленных ниже:
{2B07156F-4D87-4BBF-96A8-00FD22D413EC}
{1C2CAD09-A9ED-4AC6-8E88-04AE0627D0C9}
{0EEC6019-B513-4AC7-BD32-194C69997D94}
{A7124037-453B-46A0-B4E0-1C9BF8BD3A0B}
...
Ну что Вы в самом деле с127...
Нужно иметь список этих периодов, для того, чтобы их последовательно перебрать в порядке возрастания. А также список объектов калькуляции.

c127

А еще могу создать временную таблицу W и туда добавлять первичные ключи записей, которые обработаны, а в WHERE добавить кроме всего прочего "not in (select * from W)". Нечто похожее Вам тут уже говорили.

А смысл? Где такой вариант проходит, то он применяется, где нет - не применяется. Вариант решения задачи подбирается в зависимости от задачи, а не от "пунктика", что следует избегать курсоров, ручной навигации и др.

c127

Не приведете Вы задачу, не решаемую с помощью запросов ("Есть задачи, которые не решаются при помощи запросов" (С) iscrafm), еще раз повторяю, это строгая математическая теорема. Почитали бы теорию, не тратили бы даром силы на попытки доказать невозможное. Признайте, что Вы ошиблись.

Вы бы не тратили даром силы, а уже бы давно опубликовали здесь алгоритм хотя бы расчета себестоимости, хотя бы средневзвешенные цены. Сколько можно то.
4 дек 06, 23:56    [3490242]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Валерий Долженко (aka iscrafm)
Guest
c127
А еще могу создать временную таблицу W и туда добавлять первичные ключи записей, которые обработаны, а в WHERE добавить кроме всего прочего "not in (select * from W)". Нечто похожее Вам тут уже говорили.

нечто похожее я здесь показывал, Вы немного ошиблись: развертка BOM. Вот она построена именно по такому принципу. Посмотрите на предыдущих страницах.
5 дек 06, 00:05    [3490263]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
8|
Guest
Зл0й
8|
почему-то в голову лезут странные задачи. имеется алгоритм + ключ шифрования и текущее состояние. применяя ключ + алгоритм на состоянии, извлекаем из него новый ключ + алгоритм и следующее состояние...
интересно, не слишком ли жмет Когаловскому структура его ресурсов.

Не вижу причин почему нельзя такую задачу решить на оракле. Реализуем алгоритм шифрования на PL/SQL в виде вызываемой из запроса функции. Дальше пишем запрос с inline view и connect by ... во внешнем запросе. Принципиальных проблем я здесь не вижу.

да ну? насколько я помню, чтобы написать запрос на oracle, нужно иметь по крайней мере одну таблицу ыхых, даже если ее нет.
5 дек 06, 08:42    [3490709]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
8|
да ну? насколько я помню, чтобы написать запрос на oracle, нужно иметь по крайней мере одну таблицу ыхых, даже если ее нет.


Ну это не совсем так, можно дергать запросом коллекции. Опять же в 10-ке навертели с MODEL
5 дек 06, 09:01    [3490768]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iiiiiiiiiiiiiiiiiiiiii
Guest
млин. надцатый лист читаю, и не понимаю, о чом спор.

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

видимо даже и с наворотами скл будет не полон. (рекурсию можно придумать с перескоками и не по одной-двум, а по неопределенному заранее (на входе в алгоритм), т.е. вычислимому в процессе числу таблитц и т.п.

2.
но РСУБД как правило "комплектуются" процедурными языками (иногда - не одним), для затыка проблемы по п.1.

3.
при 2. можно заметить, что "нафигация" (в смысле сдвига в сортированном наборе относительно некоего "текущего контекста процедуры") в скл осуществима. Простым запросом с SELECT ... LIMIT OFSET.

4.
но так же можно заметить, что (многократная) "нафигация" по заранее выбранному набору таким вот как в 3. образом (через многократные SELECT ... LIMIT ... OFSET ...) непроизводительна (многократно оптимизатор повторяет уже проделанную работу). Поэтому как минимум имеем курсоры (и FOR ... IN SELECT ... LOOP-ы). Что тоже иногда не совсем оптимально с т.з. объема "производимых суммарно" (т.е. оптимизатором - неявно и процедурой - явно) вычислений. (скажем - нужны многократные переходы "по значению" в комбинации с относительными - next/prev в одном и том же заранее скомпонованном оптимайзером наборе)

5.
отступление о "нафигации": под нафигацией видимо следует понимать не только перемещения в сортированном наборе на некий шаг от "текущей позиции", но любой переход в заранее подготовленном наборе (не обязательно сортированных) данных. например переход по значению - т.е. по (уже построенному оптимайзером при выборке или вообще хранимому) хэшу, связанному списку, или по дереву. При вычислительной неполноте скл, и при вычислительной неэффективности многократных селектов в кач-ве нафигационного средства, эти (пока умозрительные, эффективные) средства очевидно должны находиться в процедурном языке. Я бы не отказался от возможности индексировать переменную табличного вида (полученную не пойми из какого набора табличек). причем иногда - несколькими индексами - если заведомо знаю, что в алгоритме потребуются многократные сдвиги вдоль различных "направлений сортировок" и переходы по различным наборам значений (с последующими шифтами). Кстати, приводимый пример про рекурсию на селектах в аксесс на практике лучше не реализовывать. Лучше открыть _табличный_ рекордсет (или рекордсеты - если "иерархия" построена по нескольким табличкам - см. случай с генеалогией на хоруме акса. - рассматривался года 2 тому.) т.е. рекордсет, позволяющий как переход по индексу (впрочем и смену индекса и переход по другому индексу) так и относительный сдвиг вдоль порядка, заданного текущим индексом рекордсета. Это много быстрее многократных селектов. Одно неудобство - если это потребуется для вызова из запроса, то придется потом отдельно заботится о закрытии рекордсета - ну тяжко в аксессе из запроса на автомате закрыть рекордсет по окончании выполнения запроса. не управляет там jet-скл прямо рекордсетами унутре VBA-шной рекурсивной ф-ии.

6.
и, как правило, слонность к рекордсетным/курсорным решениям приводит к тому, что начинаются процедурные переливания из пустого в порожнее в случаях, решаемых одним (иногда - даже простым) селектом. Ну попросту потому, что способы мышления разные. Один - чисто декларативный - т.е. (теоретико-)множественный (алгоритмическая часть возлагается на думатель - т.е. оптимизатор). Второй - чисто процедурный - т.е. "алгоритмический" (издержки - повторение реализации алгоритмов, даже самых простейших, врукопашку).

7. а вот все, что ЧАЛ рисует про семантику - ну сыршенно не пнятно. абстракция - вона и в африке абстрация. определенным смыслом ее наполняет интерпретирующий в процессе интертрепации. ну договоритесь вы чиселки (те же ключи) интерпретировать как стрелочки, а стрелочки - как взаимоотношения субъектов - и ладушки. не договорились - и какая фих разница, стрелочки у вас, или чиселки. ить без интертрепации ни то не другое ничего не означаит. (кстати, интересно, а как стрелочки в машине храняцца? неушто там склад со стрелочками в думатель встроен? прямо под неонкой, значицца - шобы лехше семантико ихо рагляжывалось).
5 дек 06, 12:36    [3492098]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
8|
Guest
Gluk (Kazan)
Ну это не совсем так, можно дергать запросом коллекции. Опять же в 10-ке навертели с MODEL

уважаемый коллега Глюк, сделайте сюрпрайз Андрею Леонидовичу. дерните запросом бинарный файл. его нафигатор точно обломится
5 дек 06, 21:40    [3495760]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Скучно что ли стало
Guest
Вы, 8, недооцениваете не мой, но все-таки нафигатор.
А "шеренга" вообще ничего пока не понимает. Хотя и знает про "комплектацию РСУБД процедурными языками". Ему про принципиальную невозможность навигации в РБД (в том числе из-за отсутствия идентификации), и, следовательно, невозможност для пользователей работать непосредственно с данными, а он про "сдвиг в сортированном наборе" в скл !?
Я уж не говорю, что 90% "запросов" (в типичных "сложных системах") составляют "запросы" типа найти конкретный экземпляр объекта или получить множество экземпляров другого объекта, "привязанных" к данному экземпляру (например, "записи" "документа", или наоборот).
А непонимающим о "семантике данных" ЗлОй настоятельно рекомендует "читать Хомского". Я же думаю, что вполне достаточно прислушаться к тому, о чем я говорю.
5 дек 06, 22:36    [3495855]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мимо пробегал...
Guest
Я же думаю, что вполне достаточно прислушаться к тому, о чем я говорю.
Эт жыш самопиарщик
6 дек 06, 00:13    [3496046]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Валерий Долженко (aka iscrafm)
Guest
Андрей Леонидович, все потихоньку идут к некоей гибридной модели данных и думаю все-таки дойдут. Тупо сидеть, каждый на своих принципах навряд ли будут, imho. Навигационные (объектные, постреляционные, иерархические, сетевые, гипертекстовые и сотоварищи) СУБД делают Set-ориентированный доступ, РСУБД предоставляют навигационный доступ (типа курсоры (ну и пусть не по физическим адресам, а по значениям атрибутов), OCCI и сотоварищи)... В итоге все сольются :) Думаю производителями СУБД больше все же движет прагматизм, чем фанатизм. В двадцатый раз, вслед за модератором, перефразируя Михалкова: Доступы разные нужны, доступы разные важны.
6 дек 06, 00:35    [3496084]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Валерий Долженко (aka iscrafm)
c127
Валерий Долженко (aka iscrafm)
что Вы будете писать в условии WHERE, чтобы получить следующую запись?

Сами же и ответили, в WHERE в каком-то виде я впишу следующий период.

Какой из перечисленных ниже:
{2B07156F-4D87-4BBF-96A8-00FD22D413EC}
{1C2CAD09-A9ED-4AC6-8E88-04AE0627D0C9}
{0EEC6019-B513-4AC7-BD32-194C69997D94}
{A7124037-453B-46A0-B4E0-1C9BF8BD3A0B}

Это у вас периоды так задаются? Ваш вопрос, если его не выдергивать из контекста, выглядел так: "Вы запросили при помощи select конкретную запись из этого набора.. что указали в WHERE?.. А потом запрашиваете следующую... по тому же продукту, только следующий период..". https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=61#3484979
Но это не важно.
Я выберу тот, который следует непосредственно за обработанным последним в смысле выбранного Вами порядка, либо первый, если процесс только начался. Или в смысле любого другого порядка, если конкретный порядок не важен, важно что порядок определить я могу всегда.

Валерий Долженко (aka iscrafm)

...
Ну что Вы в самом деле с127...
Нужно иметь список этих периодов, для того, чтобы их последовательно перебрать в порядке возрастания. А также список объектов калькуляции.

Повторяю еще раз медленно: В РСУБД СПИСОК МОЖНО ПОСТРОИТЬ ВСЕГДА, это все равно что СПИСОК ВСЕГДА ЕСТЬ.

Почитайте хоть что-нибудь из теории.

Валерий Долженко (aka iscrafm)

c127

А еще могу создать временную таблицу W и туда добавлять первичные ключи записей, которые обработаны, а в WHERE добавить кроме всего прочего "not in (select * from W)". Нечто похожее Вам тут уже говорили.

А смысл?

А смысл не обсуждается, обсуждается принципиальная возможность. Вы же сказали, что "Есть задачи, которые не решаются при помощи запросов", так вот Вам пытаются доказать ошибочность этого утверждения. Вот если бы Вы сказали "не все задачи имеет смысл решать с помощью запросов", то можно было бы обсуждать смысл. Так что теперь не нужно съежать на смысл, либо приводите аргументы в пользу правильности своего утверждения, если можете, либо признавайте его ошибочность.
6 дек 06, 01:27    [3496135]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
8|
Gluk (Kazan)
Ну это не совсем так, можно дергать запросом коллекции. Опять же в 10-ке навертели с MODEL

уважаемый коллега Глюк, сделайте сюрпрайз Андрею Леонидовичу. дерните запросом бинарный файл. его нафигатор точно обломится


Такие извращения не по моей части :) Но речь то ведь шла о принципиальной возможности, коллега ;)
6 дек 06, 09:06    [3496502]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Валерий Долженко (aka iscrafm)
Guest
c127
Это у вас периоды так задаются?

да. первый раз такое встречаете?
c127

Повторяю еще раз медленно: В РСУБД СПИСОК МОЖНО ПОСТРОИТЬ ВСЕГДА, это все равно что СПИСОК ВСЕГДА ЕСТЬ.

Повторяю медленно: ПОСТРОЙТЕ

c127

Почитайте хоть что-нибудь из теории.

кроме улыбки, подобные фразы уже ничего не вызывают. А улыбаться полезно. Продолжайте :)

c127

А смысл не обсуждается, обсуждается принципиальная возможность. Вы же сказали, что "Есть задачи, которые не решаются при помощи запросов", так вот Вам пытаются доказать ошибочность этого утверждения. Вот если бы Вы сказали "не все задачи имеет смысл решать с помощью запросов", то можно было бы обсуждать смысл. Так что теперь не нужно съежать на смысл, либо приводите аргументы в пользу правильности своего утверждения, если можете, либо признавайте его ошибочность.

Повторяю медленно:
iscrafm
Вы бы не тратили даром силы, а уже бы давно опубликовали здесь алгоритм хотя бы расчета себестоимости, хотя бы средневзвешенные цены. Сколько можно то.

я думал Вы в этот раз решили посетить топик уже с готовыми запросами, а Вы просто перефразировали предыдущий свой текст
6 дек 06, 09:15    [3496542]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
Валерий Долженко (aka iscrafm)
все потихоньку идут к некоей гибридной модели данных и думаю все-таки дойдут.

+1
6 дек 06, 09:28    [3496606]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
iscrafm
Вы бы не тратили даром силы, а уже бы давно опубликовали здесь алгоритм хотя бы средневзвешенные цены.

select средневзвешенная_цена(код_товара) from товары
Это шутка - оракл кажется пока еще не придумал соответ. агрегатную функцию.
6 дек 06, 09:36    [3496640]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
мод
select средневзвешенная_цена(код_товара) from товары
[/src]Это шутка - оракл кажется пока еще не придумал соответ. агрегатную функцию.

Хм. Если оракл не придумал - никто не мешает написать самим.

Впрочем, не вижу проблемы. Нормальное средневзвешенное спокойно считается обычными агрегатными функциями. Является ли средневзвешенная цена нормальной - не знаю, думаю, что является.
6 дек 06, 10:14    [3496860]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
softwarer
мод
select средневзвешенная_цена(код_товара) from товары
[/src]Это шутка - оракл кажется пока еще не придумал соответ. агрегатную функцию.

Хм. Если оракл не придумал - никто не мешает написать самим.

Впрочем, не вижу проблемы. Нормальное средневзвешенное спокойно считается обычными агрегатными функциями. Является ли средневзвешенная цена нормальной - не знаю, думаю, что является.


+аналитика
6 дек 06, 10:16    [3496886]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Gluk (Kazan)
+аналитика

Нафига она там? Для вычисления средневзвешенного достаточно агрегатной SUM.
6 дек 06, 10:20    [3496909]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Это на случай, если будет сказано, что sum и count фигня, а надо было посчитать, скажем линейную регрессию
6 дек 06, 10:30    [3496986]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Валерий Долженко (aka iscrafm)
Guest
softwarer
мод
select средневзвешенная_цена(код_товара) from товары
[/src]Это шутка - оракл кажется пока еще не придумал соответ. агрегатную функцию.

Хм. Если оракл не придумал - никто не мешает написать самим.

Впрочем, не вижу проблемы. Нормальное средневзвешенное спокойно считается обычными агрегатными функциями. Является ли средневзвешенная цена нормальной - не знаю, думаю, что является.

можно пример?
6 дек 06, 10:50    [3497136]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Ребяты, поздравьте меня: я прочитал всю эту тему (63 страницы)! Всем участникам респект. Даже ЧАЛу благодарность, за то, что собой демонстрировал такой "фон", что остальные выглядели ышо умнее.

Кстати, как мне кажется, спор про навигацию между Валерем и Co уже исчерпал себя. Такое чувство, что он идет по инерции со всех сторон.

P.S. Мне кажется, что написать бот "ЧАЛ" проще простого. Я внимательно посмотрел -- все его сообщения на 90% одно и то же, чистый copy-paste, а практически остальное -- упоминание имен собеседников.

P.P.S Модератору.Я тоже что-то не понимаю, за что банили iscrafm'а. На общем уровне г-н Долженко был вполнее корректен и адекватен.
6 дек 06, 10:51    [3497148]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
8|
Guest
Скучно что ли стало
Вы, 8, недооцениваете не мой, но все-таки нафигатор.

безусловно, Истинный Нафигатор без труда нафигачит состояния в стопку. но ваш нафигатор испорчен идентификацией. мало того, что он не в состоянии решать истинно нафигационные задачи, идентифицированная нафигация семантически противоречива. поэтому вам приходится постулировать семантическую непротиворечивость вашей семантики. ну дык, извините, любой оператор нафигатора может постулировать правильность нафигации своего нафигатора.
6 дек 06, 11:33    [3497567]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 58 59 60 61 62 [63] 64 65 66 67 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить