Re: Firebird, MysQL PostgreSQL
Добрый день, Oleg! Вы писали от Thu, 14 Sep 2006 16:53:18 +0400: ??>> Вопрос почему 1С выбрала Postgre а не FB 1 Бесплатная 2 Требуемый 1С функционал реализован больше чем у других 3 В команде есть специ готовые вести проект Собственно мне жадь что это не FB По 1 пункту FB проходит 3 пункт это субьективная ситуация 2 пункт интересен, вопросом чем FB проигрывает Postgre с точки зрения функциональности для ERP систем класса 1С Возможно у Postgre большая совместимость с MSSQL ?? С Уважением, Константин Зайцев.
Re: Firebird, MysQL PostgreSQL
Привет, Konstantin! Вы пишешь к Oleg LOA 14 сентября 2006: [Sorry, skipped] KZ> Возможно у Postgre большая совместимость с MSSQL ?? Интересно, что ты вкладываешь в понятие "совместимости с MSSQL" ?.. -- With best regards, Alex Cherednichenko.
Re: Firebird, MysQL PostgreSQL
Добрый день, Alex! Вы писали to Konstantin Zaitcev от Thu, 14 Sep 2006 18:30:44 +0400: KZ>> Возможно у Postgre большая совместимость с MSSQL ?? AC> Интересно, что ты вкладываешь в понятие "совместимости с MSSQL" ?.. Если программа в данном случае 1С на уровне сервера приложений поддерживает 2 БД, значит что синтаксис версий SQL и их возможности близки друг к другу, Я не уверен но скорей всего 1С пользуется или страндартной абстракцией на уровне доступа к БД ODBC, ADO или своими собственными компонентами доступа имеющиие общий абстрактный класс. На основе совместимости получает деньги тот же проект FYRACLE. Совместимость не совсем хорошее слово, в данном контексте я имел вв виду некий интегральный коээфицент, определяющий сложность портирования приложения с одного сервера БД на другой или сложность поддержки в приложении 2 разных серверов БД. Из это факта следует что у Postgre данный коэффициент лучше чем у FB по отношению к MSSQL. С Уважением, Константин Зайцев.
Re: Firebird, MysQL PostgreSQL
Hello, Konstantin! You wrote to Oleg LOA on Thu, 14 Sep 2006 18:26:00 +0400: ??>>> ÷ÏÐÒÏÓ ÐÏÞÅÍÕ 1ó ×ÙÂÒÁÌÁ Postgre Á ÎÅ FB ??>>> 1 âÅÓÐÌÁÔÎÁÑ ??>>> 2 ôÒÅÂÕÅÍÙÊ 1ó ÆÕÎËÃÉÏÎÁÌ ÒÅÁÌÉÚÏ×ÁÎ ÂÏÌØÛÅ ÞÅÍ Õ ÄÒÕÇÉÈ ??>>> 3 ÷ ËÏÍÁÎÄÅ ÅÓÔØ ÓÐÅÃÉ ÇÏÔÏ×ÙÅ ×ÅÓÔÉ ÐÒÏÅËÔ ËÁË ÔÏ ÕÐÕÓËÁÅÔÓÑ ×ÏÚÍÏÖÎÏÓÔØ ÎÁ ÐÏÓÔÇÒÅÓÅ ÐÏÄÄÅÒÖÉ×ÁÔØ ËÌÁÓÔÅÒÎÏÓÔØ. äÌÑ 1ó 8,1 ÜÔÏ ×ÁÖÎÏ ôÕÔ Õ FB ÐÒÏÂÌÅÍÙ. îÏ, ÏÔÈÏÄÑ ×× ÓÔÏÒÏÎÕ ÏÔ ÓÕÔÉ ×ÏÐÒÏÓÁ, ÌÉÞÎÏ ÑÔÁË É ÎÅ ÐÏÎÑÌ 1ó , ÞÅÍ ÉÍ ÎÅ ÕÇÏÄÉÌ Sybase.é ÂÅÓÐÌÁÔÎÙÅ ×ÅÒÓÉÉ ÅÓÔØ, É ÐÏÄ ÌÉÎÕÈÏÍ ÒÁÂÏÔÁÅÔ, É ÓÉÎÔÁËÓÉÓ Ó MSSQL ÐÅÒÅÓÅËÁÅÔÓÑ ÇÏÒÁÚÄÏ ÓÉÌØÎÅÅ ÏÓÔÁÌØÎÙÈ ÂÁÚ, ÄÁ É ÐÏ ÌÏÇÉËÅ ÒÁÂÏÔÙ ÔÏÖÅ ÂÏÌÅÅ ÐÏÈÏÖ. á ÔÁË ÏÎÉ ×ÙÂÒÁÌÉ ÎÅ ÓÁÍÕÀ ÒÁÓÐÒÏÓÔÒÁÎÅÎÎÕÀ óõâä, ÞÅÇÏ-ÔÏ ÔÁÍ ÉÈÍÅÎÉÌÉ (ËÏÌÌÌÜÊÔÙ É ÐÏÄÅÒÖËÁ ÑÚÙËÏ× ÔÏÞÎÏ) Ó ÍÁÌÙÍ ÓÏÏÂÝÅÓÔ×ÏÍ ÎÁ ÐÏÓÔóóóò-ÏÍ ÐÒÏÓÔÒÁÎÓÔ×Å. ÷-ÌÏÂÝÅÍ ÓÔÒÁÎÎÏÅ ÒÅÛÅÎÉÅ. With best regards, veliks. E-mail: [EMAIL PROTECTED]
Re: Firebird, MysQL PostgreSQL
"veliks" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > как то упускается возможность на постгресе поддерживать кластерность. Для 1С > 8,1 это важно Это не важно. Кому нужны "кластера" могут спокойно купить и использовать MSSQL. > тоже более похож. А так они выбрали не самую распространенную СУБД, чего-то > там ихменили (колллэйты и подержка языков точно) с малым сообществом на > постСССР-ом пространстве. В-лобщем странное решение. Решение может быть сколь угодно странным. Надеюсь никто не сомневается в том что 1С умеет на своих решениях зарабатывать деньги? :-):-):-)
Re: Firebird, MysQL PostgreSQL
veliks wrote: как то упускается возможность на постгресе поддерживать кластерность С каких это пор постгрес поддерживает кластеры? -- Дмитрий Еманов
Re: Firebird, MysQL PostgreSQL
veliks пишет: Но, отходя вв сторону от сути вопроса, лично ятак и не понял 1С , чем им не угодил Sybase.И бесплатные версии есть, и под линухом работает, Вот именно! Бесплатные версии ASE есть только под Linux. А маленькие фирмочки, на которые позиционируют постгресовскую версию 1с, могут и не иметь в штате админа, который в состоянии сопровождать линух, да еще и с ASE на борту. > А так они выбрали не самую распространенную СУБД Распространенность понемногу растет после выхода pg8 под win, а с 1с вырастет еще заметнее.
Re: Firebird, MysQL PostgreSQL
Hello, Oleg! You wrote on Fri, 15 Sep 2006 10:41:23 +0400: ??>> ËÁË ÔÏ ÕÐÕÓËÁÅÔÓÑ ×ÏÚÍÏÖÎÏÓÔØ ÎÁ ÐÏÓÔÇÒÅÓÅ ÐÏÄÄÅÒÖÉ×ÁÔØ ËÌÁÓÔÅÒÎÏÓÔØ. ??>> äÌÑ 1ó 8,1 ÜÔÏ ×ÁÖÎÏ OL> üÔÏ ÎÅ ×ÁÖÎÏ. ëÏÍÕ ÎÕÖÎÙ "ËÌÁÓÔÅÒÁ" ÍÏÇÕÔ ÓÐÏËÏÊÎÏ ËÕÐÉÔØ É OL> ÉÓÐÏÌØÚÏ×ÁÔØ MSSQL. éÚ×ÉÎÉÔÅ ïÌÅÇ, ÎÏ ÐÒÅÄÓÔÁ×ÉÔÅÌÉ 1ó ÉÍÅÎÎÏ ÞÔÏ ÏÐÉÒÁÀÔÓÑ ÎÁ ÜÔÏ × Ó×ÏÉÈ ÐÒÅÚÅÎÔÁÃÉÑÈ. ÉÍÅÎÎÏ ÞÔÏ ×ÙÄÅÌÑÀÔ ÏÓÏÂÏ. á ÎÁÓÞÅÔ MSSQL - ÅÓÌÉ ÐÏÓÞÉÔÁÔØ ËÁËÏÅ ÖÅÌÅÚÏ É ÓÏÆÔ ÏÎÉ ÒÅËÏÍÅÎÄÕÀÔ ... ÕÖ ÌÅÇÞÅ ÐÏÓÔÇÒÅÓ ×ÙÕÞÉÔØ :)). With best regards, veliks.
Re: Firebird, MysQL PostgreSQL
Hello, Dmitry! You wrote on Fri, 15 Sep 2006 11:15:49 +0400: DY> veliks wrote: ??>> ??>> êàê òî óïóñêàåòñÿ âîçìîæíîñòü íà ïîñòãðåñå ïîääåðæèâàòü êëàñòåðíîñòü DY> Ñ êàêèõ ýòî ïîð ïîñòãðåñ ïîääåðæèâàåò êëàñòåðû? Íàâåðíîå íàäî ñïðîñèòü 1ñ-åâ . Ó íèõ ýòî â ïðåçåíòàöèÿõ íàðèñîâàíî è àêòèâíî ïðîïîãàíäèðóåòñÿ :)) With best regards, veliks.
Re: Firebird, MysQL PostgreSQL
Hello, Alexander! You wrote on Fri, 15 Sep 2006 11:16:36 +0400: ??>> îÏ, ÏÔÈÏÄÑ ×× ÓÔÏÒÏÎÕ ÏÔ ÓÕÔÉ ×ÏÐÒÏÓÁ, ÌÉÞÎÏ ÑÔÁË É ÎÅ ÐÏÎÑÌ 1ó , ÞÅÍ ??>> ÉÍ ÎÅ ÕÇÏÄÉÌ Sybase.é ÂÅÓÐÌÁÔÎÙÅ ×ÅÒÓÉÉ ÅÓÔØ, É ÐÏÄ ÌÉÎÕÈÏÍ ÒÁÂÏÔÁÅÔ, AG> ÷ÏÔ ÉÍÅÎÎÏ! âÅÓÐÌÁÔÎÙÅ ×ÅÒÓÉÉ ASE ÅÓÔØ ÔÏÌØËÏ ÐÏÄ Linux. á ÍÁÌÅÎØËÉÅ AG> ÆÉÒÍÏÞËÉ, ÎÁ ËÏÔÏÒÙÅ ÐÏÚÉÃÉÏÎÉÒÕÀÔ ÐÏÓÔÇÒÅÓÏ×ÓËÕÀ ×ÅÒÓÉÀ 1Ó, ÍÏÇÕÔ É ÎÅ AG> ÉÍÅÔØ × ÛÔÁÔÅ ÁÄÍÉÎÁ, ËÏÔÏÒÙÊ × ÓÏÓÔÏÑÎÉÉ ÓÏÐÒÏ×ÏÖÄÁÔØ ÌÉÎÕÈ, ÄÁ ÅÝÅ É AG> Ó ASE ÎÁ ÂÏÒÔÕ. éÍÅÑ 7ÌÅÔÎÉÊ ÏÐÙÔ ÒÁÂÏÔÙ Ó 1ó É ÉÈ ÐÒÅÄÓÔÁ×ÉÔÅÌÑÍÉ Õ ÍÅÎÑ ÏÞÅÎØ ÓÅÒØÅÚÎÙÅ ÓÏÍÎÅÎÉÑ × ÉÈ ÓÐÏÓÏÂÎÏÓÔÉ ËÁÞÅÓÔ×ÅÎÎÏ ÐÅÒÅÎÅÓÔÉ É ÐÏÄÄÅÒÖÉ×ÁÔØ ÓÒÁÚÕ 2 ÒÁÚÎÙÈ ÓÅÒ×ÅÒÁ óõâä. IMHO ËÏÎÅÞÎÏ. With best regards, veliks.
Re: Firebird, MysQL¸ PostgreSQL
Hello, Alexey Popov said the following on 19.09.2006 16:24: >> 8. ФБ не имеет кэша выполненных >> запросов, что существенно затрудняет >> его применение в интернете. Когда одна >> страница открывается сотни раз в день. > > Нет, такую порнография в сервер не надо. > Это можно поручить клиенту. Клиентов несколько. Нагрузка распределена между несколькими веб-серверами, но работают они с одной и той же БД. -- Oleg
Re: Firebird, MysQL¸ PostgreSQL
Oleg Deribas wrote: Нет, такую порнография в сервер не надо. Это можно поручить клиенту. Клиентов несколько. Нагрузка распределена между несколькими веб-серверами, но работают они с одной и той же БД. 1. Кэш на каждом клиенте. 2. Третье звено. Какой смысл распределять веб сервер если узкое место - БД? -- --- Home Page http://ok.novgorod.net/ap ---
Re: Firebird, MysQL¸ PostgreSQL
Hello, Alexey Popov said the following on 19.09.2006 18:07: >>> Нет, такую порнография в сервер не надо. >>> Это можно поручить клиенту. >> >> Клиентов несколько. Нагрузка распределена между несколькими >> веб-серверами, но работают они с одной и той же БД. > > 1. Кэш на каждом клиенте. 1.1. Это снижает эффективность кэша, пропорционально количеству клиентов, т.к. обычно клиенты, в случае web, живут очень недолго. 1.2. К примеру, в php adodb есть кэш, но его эффективность все равно невысока. > 2. Третье звено. Третье звено - это понятно, у тебя уже заработал memcached с firebird? Или предлагаешь писать третье звено под каждый проект самому? > Какой смысл распределять веб сервер если узкое место - БД? Так о том и речь. Если использовать firebird в стандартном web-проекте, он будет узким местом. Хотя я для интереса поставил bitweaver под firebird и оно вполне себе работает ;-) -- Oleg
Re: Firebird, MysQL¸ PostgreSQL
Oleg Deribas wrote: 1. Кэш на каждом клиенте. 1.1. Это снижает эффективность кэша, пропорционально количеству клиентов, т.к. обычно клиенты, в случае web, живут очень недолго. Под клиентом я имел ввиду комп. Или ты про случай когда каждый web клиент создаёт новое подключение к базе? 2. Третье звено. Третье звено - это понятно, у тебя уже заработал memcached с firebird? Или предлагаешь писать третье звено под каждый проект самому? Так о том и речь. Если использовать firebird в стандартном web-проекте, он будет узким местом. Хотя я для интереса поставил bitweaver под firebird и оно вполне себе работает ;-) Вообщем если есть спрос, то в принципе задача решает выпуском спец. модуля которые бы занимался кэшированием. -- --- Home Page http://ok.novgorod.net/ap ---
Re: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
Константин wrote: Или это уже не соответствует действительности и background можно и на класике включить ? А в каком из процессов будем включать background? ;) -- Regards. Ded.
Re: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
Константин wrote: Или это уже не соответствует действительности и background можно и на класике включить ? D> А в каком из процессов будем включать background? ;) Дык, а что, нельзя отдельный запустить ? - В сад. - Вы будете там петь? - Нет, вы будете там слушать. (С) -- Regards. Ded.
Re: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
Константин wrote: Т.е., как я понял, некому сделать... Типа есть более важные задачи ? Мусик, не нервируй меня (С). На грубость нарываешься. Или "это" просто не имеет смысла ? Настолько, что непонятно как такая идея вообще могла зародиться в сером веществе. -- Regards. Ded.
Re: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
Константин wrote: Хоть я и "умолк" :) но всё-же ляпну ... Девиз доброй половины этой ветки. Вмешиваться уже не хочется. -- Дмитрий Еманов
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Hello, Vlad! Vlad Horsun wrote: Предлагаю всем - перед тем, как что-то предложить или критиковать, подумать - а как это можно сделать иначе, а зачем это нужно делать иначе и почему сейчас это сделанно именно так. :-) я уже это пробовал. не работает :-( -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
Hello, Konstantin! Константин wrote: Хоть я и "умолк" :) но всё-же ляпну ... Почему ? сначала прочитай www.ibase.ru/devinfo/garbage.htm и www.ibase.ru/devinfo/sweep.htm затем подумай об отличиях классика и суперсервера. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"Boltik Evgeny" ... > А нафига шарить по всему файлу БД Согласен > когда можно было сделать что то списка > страниц со ссылками на старые записи и пробежав только по этим страницам в Ну и будет у тебя список со всей базой - и шо ? > базе меняется не вся информация а только малая часть ее. Та ты шо ?! Т.е. берём твои БД за образец и тюним движок под них ? Ты уж как-нибудь сам... > Нафига лопатить все. А вот это - правильно > Раньше когда я работал с собственным форматом файлов баз данных я имел > на каждую запись 4 байта данных для ссылки на предпоследнюю удаленную > запись, а в шапке файла была ссылка на самую последнюю запись. И как только > я добавлял новую запись я проверял есть ли удаленная запись если есть ее > перезаписывал а указатель предыдущей удаленной делал как текущую уделенную и > записывал в шапку. И сколько конкурентных тр-ций поддерживал твой "движок" ? А что же ты с ним сейчас не работаешь ? > Получается что -housekeeping 100 приведет к еще большим тормозам, а я так > надеялся что наоборот :(. С какой стати ты на это надеялся ? -- Хорсун Влад PS Я уже просил _сначала_ думать, а _потом_ писать PPS Также я писал, что способы оптимизировать свип, дабы он не читал всю БД, уже есть и скорее всего будут реализованы в 3.0. Пофантазируйте на другие темы, плс
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"Boltik Evgeny" ... > > >> когда можно было сделать что то списка > >> страниц со ссылками на старые записи и пробежав только по этим страницам > >> в > > > >Ну и будет у тебя список со всей базой - и шо ? > > С чего это со всей базой. Старые периоды ни кто не правит практически. > Правится и изменяется только новая информация. Так может возьмём твою бд за образец для всех остальных ? Для биллингов, crm'ов, etc ? > >> базе меняется не вся информация а только малая часть ее. > > > >Та ты шо ?! Т.е. берём твои БД за образец и тюним движок под них ? > > Ты уж как-нибудь сам... > > Причем здесь мои базы. У одного клиента вылезли тормоза и ты думаешь теперь > что у всех и только на моей базе. Нук раскажи нафига править данные > складского учета или бух-го за 2004 год? И что будет правится весь 2004 год? Женя, если ты не видишь ничего дальше собственного бухучёта, то не нада рассказывать за других, да ? > Суть была не в транзакциях а в принципе не разростания файла базы данных > т.к. удалялось и добавлялось много записей. Нафига тогда тут это рассказывать ? Я же не описываю тут все свои курсовые... > >> Получается что -housekeeping 100 приведет к еще большим тормозам, а я так > >> надеялся что наоборот :(. > > > >С какой стати ты на это надеялся ? > > Документацию не читал т.к. была на не русском. Вот молодец, так и надо > > PS Я уже просил _сначала_ думать, а _потом_ писать > > А кто сказал что я не думаю? Я высказал то что я делал для ускорения и > уменьшения файла. И что теперь молчать и не предлагать вообще что ли. > Получается вообще ничего не предлагать. Я и так практически только читаю > конфу. Если имеешь что предложить, то нужно быть готовым отстаивать своё предложение. И делать его в человеческом виде, а не как поток сознания, пролившийся ниже > На держи фантазию Ты это уже описывал с год назад. За это время ты не смог даже вразумительно сформулировать свою фантазию - либо оно тебе не надо, либо тебе пофигу понимает ли тебя кто-нить ещё, либо и то, и то > Я постоянно впарываюсь, да скорей всего и не я один в ситуации когда данные > можно было найти быстро а они ищутся долго. Происходит много лишних чтений. а нефиг вводить столько данных ;) > Дак вот есть мысля как улучшить этот механизм. Сейчас нужно точное > совпадение написания того что в computed by написано. > > И так есть 2 таблицы > > T1 > F1 > F2 > > T2 > F1 > F3 > > есть вьюха > > V1 > F1, F2, F3 > from T1, T2 > where T1.F1 = T2.F1 > > а теперь выполняем такой запрос > > select * from V1 where F2 = x and F3 = y при чём тут computed by ? > ну естественно оптимизатор в трансе придумал что ему вздумалось из таблицы > T1 масса ненужных чтений какой транс ? где реальные примеры с цифрами ? > а вот теперь давай ему поможем и создадим индекс > CREATE INDEX idx2 ON T2 ( > (select F2 from T1 where T1.F1 = T2.F1) [as F2], > F3) ты понимаешь что такое индекс ? > а вот после этого индекса запрос будет летать ...низко-низко... > а) теперь оптимизатор знает что поле F2 существует в индексе и должен думать > что индекс как буд то выглядит так CREATE INDEX idx2 ON T2 (F2, F3) то есть > мы обманываем оптимизатор поле в нем comp by но физически оно отсутствует > ситуация просто супер не надо плодить избыточных данных индекс - уже избыточные данные > б) действия сервера он должен создать внутренний триггер у таблицы T1 на > обновление на случай изменения F2 самому сложно создать ? и что этот триггер должен делать ? > Сейчас приходится вводить доплнительное поле в T2 F2x и создавать индекс > CREATE INDEX idx2 ON T2 (F2x, F3) а в чём проблемы ? ещё и триггер создавать надо, к счастью, вполне нормальный... а если на одну запись t2 приходится 2 в t1 - шо тогда ? или в твоей образцовой бд такого не бывает, а на остальных нам, как обычно, начхать ? > А все по той причине что если не создавать такую избыточность на один селект > тратится более 1 секунды (это на моем P4 3Гц) а у клиентов PIII стоят. После > создания избыточности получаем запрос на милисикунды. А при выполнении > отчетов скорость выростает и мы экономим минуты клиентов и массу времени > разработчиков. прям массу ? а если её ещё на ускорение времени разработчиков умножить - этож будет сила времени разработчиков ! > Вывод мы получим теже действия которые делает пользователь при обновлении > данных, то есть на производительность при обновлении данных никак не > повлияет т.к. обновление информыции одинакова не зависимо ни отчего. А вот с какой стати ? триггер твой волшебный святой дух обновлять будет ? > избыточность данных будет удалена из базы и улучшится производительность. так ты материализованные представления хочешь, что ли ? (воскликнул я, после двадцатого перечитывания этого опуса...) надо же так замаскировать... Пока нет желающих это делать -- Хорсун Влад
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Hello, Evgeny! Boltik Evgeny wrote: Ну накоец теперь мысь которую я пытаюсь довести до вас. Если сделать возможным отсутствие физического присутствия полей prod, pok в t2 с помощью такого хитрого индекса CREATE INDEX idx2 ON T2 ( (select prod from T1 where t1.id = t2.t1id) [as prod], (select pok from T1 where t1.id = t2.t1id) [as pok], kolvo) Жень, эту мысль ты можешь закопать очень глубоко, и успокоиться. В ключах нет идентификаторов транзакций. А значит в запросе select * from t1, t2, ts where ts.fs = :P1 and ts.prod = t1.prod and t1.pok = :pok and t1.id = t2.t1id and t2.kolvo > 0 может спокойно использовать индекс idx2 для плана а значит без версий записей таблицы t1 нельзя будет установить, какое именно значение ключа относится к конкретной версии записи в t2. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Dmitri Kuzmenko wrote: Жень, эту мысль ты можешь закопать очень глубоко, и успокоиться. Ааа ты теерпелииивый... :-D Я с первого взгляда понял что мне криатифф ниасилить :-D -- Regards. Ded.
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Hello, Evgeny! Boltik Evgeny wrote: Жень, эту мысль ты можешь закопать очень глубоко, и успокоиться. В ключах нет идентификаторов транзакций. Странно а как же тогда определеяется индексное чтение. очень просто - сначала по совпадению ключей выбираются номера записей. Дальше эти номера записей сортируются, и над ними выполняются операции and/or и т.п., если нужно. После чего, когда доходит до выборки записей, движок выбирает каждый номер записи из списка по очереди, и уже дальше смотрит, можно видеть конкретную версию или нельзя. Согласен я не сильно силен в структуре хранения данных в ФБ, но все же высказал идею к которой можно было бы стремится. физика БД - это в основном математика и факты. стремиться можно много к чему, но из молотка не сделать колесо. Я не к тому что сделано плохо или хорошо, но для конкретного движка есть МЕХАНИЗМЫ ДОСТУПА. www.ibase.ru/devinfo/dataaccesspaths.htm постепенно оптимизировалос. Почемубу не начать такую реализацию. см выше. Как это нельзя можно на каждый случай свой ключь. рекомендую переосмыслить. если нужно - почитать хотя бы "проектирование структур баз данных" Тиори и Фрая. Если не хочешь влезать - тогда совсем не читай. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Dmitri Kuzmenko wrote: > Hello, Evgeny! > > Boltik Evgeny wrote: > > >>Жень, эту мысль ты можешь закопать очень глубоко, и успокоиться. > >>В ключах нет идентификаторов транзакций. > > > > Странно а как же тогда определеяется индексное чтение. > > очень просто - сначала по совпадению ключей выбираются номера записей. > Дальше эти номера записей сортируются, А вроде битовый массив создается. Для чего сортировать номера записей?
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
freemanzav wrote: Дальше эти номера записей сортируются, А вроде битовый массив создается. Для чего сортировать номера записей? Битовая карта упорядочена по определению. Т.е. включение в нее номеров записей равносильно их сортировке (для внешнего наблюдателя). -- Дмитрий Еманов
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Dmitri Kuzmenko wrote: > или хорошо, но для конкретного движка есть МЕХАНИЗМЫ ДОСТУПА. > www.ibase.ru/devinfo/dataaccesspaths.htm Коррекция: 1.2.1. Битовые карты, 2-й абзац, 3-е предложение: "Эта карта представляет собой разр_я_женный битовый массив, где ..." скорее всего имелось в виду "разр_е_женный", от "редкий". Иначе получается, что его или лишили заряда, или нарядили :-). -- wbr, sb
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"Serg Bormant" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > Коррекция: > > 1.2.1. Битовые карты, 2-й абзац, 3-е > предложение: > "Эта карта представляет собой > разр_я_женный битовый массив, где ..." > > скорее всего имелось в виду > "разр_е_женный", от "редкий". Иначе > получается, > что его или лишили заряда, или нарядили > :-). > В математике (начиная с высшей) есть понятия "разряженная матрица", "разряженный массив"..., но нет понятия "редкий массив". По крайней мере за последние 30 лет я о "редких матрицах" не слышал 8-) -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"ArtGal" сообщил/сообщила в новостях следующее: В математике (начиная с высшей) есть понятия "разряженная матрица", "разряженный массив"..., Я что это такое? Вот разреженные матрицы я хорошо помню, это матрицы, у которых большинство элементов - нули. Для них специальные выч.методы применяются. А разрЯженные - это как, в тряпки от Гуччи? ;-) Grue
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
ArtGal wrote: > "Serg Bormant" <[EMAIL PROTECTED]> > В математике (начиная с высшей) есть понятия > "разряженная матрица", "разряженный массив"..., > но нет понятия "редкий массив". > По крайней мере за последние 30 лет я о > "редких матрицах" не слышал 8-) Не совсем так. Про разр_е_женные (сиречь рЕдки в них ненулевые элементы) матрицы и массивы знаю. К сожалению, приходится слышать и про разр_я_женные, только неправильно это, этимология у понятия другая. -- wbr, sb
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Serg Bormant wrote: Не совсем так. Про разр_е_женные (сиречь рЕдки в них ненулевые элементы) матрицы и массивы знаю. К сожалению, приходится слышать и про разр_я_женные, только неправильно это, этимология у понятия другая. Поправим статью, не вопрос :-) -- Дмитрий Еманов
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Valery Gruzdev wrote: > "ArtGal" сообщил/сообщила в новостях следующее: > > > В математике (начиная с высшей) есть понятия > > "разряженная матрица", "разряженный массив"..., > > Я что это такое? > > Вот разреженные матрицы я хорошо помню, это матрицы, у которых большинство > элементов - нули. Вообще, не совсем так. Не большинство элементов нули, а большинство элементов имеют одно значение. >Для них специальные выч.методы применяются. > В FB скорее всего применяются обычные битовые массивы, где кол-во элементов равно количеству записей в таблицах . Ну мне так кажется.
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"Serg Bormant" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > Не совсем так. Про разр_е_женные (сиречь > рЕдки в них ненулевые элементы) > матрицы и массивы знаю. К сожалению, > приходится слышать и про разр_я_женные, > только неправильно это, этимология у > понятия другая. > Прошу прощения. Был не прав. Глаза замылились 8-) Прочитал разрЕженные (то что ждал) -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"freemanzav" ... > В FB скорее всего применяются обычные > битовые массивы, где кол-во элементов > равно количеству записей в таблицах . > Ну мне так кажется. Ошибаешься -- Хорсун Влад
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Serg Bormant wrote: Тогда дополню :-) Исправлено, спасибо. Сегодня обновим на сайте. -- Дмитрий Еманов
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Hello, freemanzav! freemanzav wrote: А вроде битовый массив создается. Для чего сортировать номера записей? чтобы выбирать записи с диска в наиболее оптимальном порядке. Ключи отсортированы по своему, а записи лежат как попало. Если номера записей, полученные из ключей не сортировать, то тогда при выборке по индексу сервер будет "скакать" по страницам. Эти "скачки" происходят при ORDER BY по индексу, когда сервер вынужден перебирать ключи в порядке индекса и по мере перебора вытаскивать записи с диска. Поэтому примерно в половине случаев ORDER BY по индексу хуже чем ORDER BY с сортировкой - при order by по индексу при большом числе записей страницы вытесняются из кэша, и конечный IO может быть много выше чем прямая сортировка. у меня есть пример под это дело, я публиковал его на sql.ru: Производительность сортировки и выборки в порядке индекса -- Давайте попробуем на практике проверить тезисы, которые были выдвинуты в конце предыдущего раздела. Для сравнения взята таблица с 14 миллионами записей (средний размер записи 117 байт, общий объем таблицы 1.86 гигабайт). По данной таблице есть 2 индекса с разной селективностью (информация скопирована из IBAnalyst. тест проводился на Firebird 1.5.2 SS) Index Depth Keys Key Len Max Dup Total Dup Uniques Selectivity Size, mb A 3 14287963 0.00 4827799 142865151448 0.0006906 82.03 B 3 14287963 1.00 100 6573235 7714728 0.001 99.52 Как видно из таблицы, индексы A и B по объему примерно одинаковы (по числу ключей они идентичны), однако по числу уникальных ключей сильно отличаются. Индекс B имеет большое число разных ключей и высокую селективность, а индекс A - всего 1448 разных значений ключей. Причем, индекс A при равномерном распределении этих уникальных значений имел бы по ~10 тысяч одинаковых ключей (для каждого уникального значения - Keys/Uniques), однако наблюдается явный перекос, то есть число ключей в этом индексе с каким-то одним значением равно ~4.8 миллионов (MaxDup) - это треть от общего числа ключей. У индекса B максимальное количество одинаковых ключей равно 100, поэтому относительно общего числа ключей этот индекс можно считать почти уникальным. Для начала имеет смысл выполнить запрос select count(*) from table который не будет использовать индексы и даст возможность оценить время выполнения запросов с использованием индексов. Prepare time = 0ms Execute time = 42s 500ms Avg fetch time= 42 500.00 ms Current memory= 1 095 520 Max memory= 19 360 784 Memory buffers= 2 048 Reads from disk to cache = 118 792 Writes from cache to disk = 6 Fetches from cache= 28 814 893 Теперь выполним 2 запроса, которые для группировки будут использовать индексы A и B (планы запросов выбирает сервер). Эти запросы "тяжелее" простого count по всей таблице, т.к. им нужно подсчитать число одинаковых записей по каждой группе разных значений столбца: SELECT A, COUNT(A) FROM TABLE GROUP BY A PLAN (TABLE ORDER A) Prepare time = 0ms Execute time = 45m 55s 469ms Avg fetch time= 153 081.61 ms Current memory= 19 225 868 Max memory= 19 275 704 Memory buffers= 2 048 Reads from disk to cache = 3 733 434 Writes from cache to disk = 0 Fetches from cache= 42 869 143 SELECT B, COUNT(B) FROM TABLE GROUP BY B PLAN (TABLE ORDER B) Prepare time = 0ms Execute time = 63ms Avg fetch time= 3.50 ms Current memory= 1 105 516 Max memory= 19 360 784 Memory buffers= 2 048 Reads from disk to cache = 48 Writes from cache to disk = 0 Fetches from cache= 12 495 Разница кажется фантастической. Обратите внимание, что в первом случае сервер произвел 3.7 миллионов чтений страниц с диска, когда сама таблица занимает на диске 118.7 тысяч страниц, а индекс - 5250 страниц. Об этом эффекте было сказано в начале данного раздела - чтение в порядке индекса приводит к постоянному вытеснению страниц из кэша, и ускорить этот запрос можно только усовершенствованием дисковой подсистемы сервера. Одновременно мы имеем обратный эффект - уникальных значений в индексе A всего 1448, поэтому после того как запрос выполнился, он, фактически, выдал нам сразу весь результат. Второй запрос, с выборкой в порядке индекса B, несмотря на мгновенность выполнения выдает только часть записей в grid, поэтому то же самое считывание страниц и их вытеснение из кэша может начаться по мере того, как пользователь будет нажимать в DBGrid кнопку PageDn (или стрелку вниз). То есть, первый запрос работает дольше, но выдает весь результат почти сразу, а второй запрос работает моментально, но будет "тормозить" по мере выдаче результата. Теперь попробуем отключить использование индекса в первом запросе, и посмотреть - буде
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Dmitri Kuzmenko wrote: > Hello, freemanzav! > > freemanzav wrote: > > > А вроде битовый массив создается. Для > > чего сортировать номера записей? > > чтобы выбирать записи с диска в наиболее > оптимальном порядке. Ключи отсортированы > по своему, а записи лежат как попало. > Если номера записей, полученные из ключей > не сортировать, то тогда при выборке по индексу > сервер будет "скакать" по страницам. Блин, запутался я с этими битовыми картами. Надо полагать, что они физически хоть и являются цепочками структур, для пользователя это все равно массив, где индекс элемента является номером записи. Или нет?
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"freemanzav" ... > Блин, запутался я с этими битовыми > картами. Надо полагать, что они > физически хоть и являются цепочками > структур, для пользователя это все > равно массив, где индекс элемента > является номером записи. Или нет? Для пользователя их вообще нет :) -- Хорсун Влад
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Пользователи бывают разные. Пользователь - человек, который что то использует (юзает). В данном случае я говорю о людях, которые используют класс битмапа для разработки. Их вроде даже иногда разработчиками называют :)
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Hello, freemanzav! freemanzav wrote: Блин, запутался я с этими битовыми картами. Надо полагать, что они физически хоть и являются цепочками структур, для пользователя это все равно массив, где индекс элемента является номером записи. Или нет? какая тебе разница? :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Dmitri Kuzmenko wrote: > Hello, freemanzav! > > freemanzav wrote: > > какая тебе разница? :-) > > -- > Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34 Да никакой. Просто делать сегодня нечего, хотелось узнать для общего развития.
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Hello, freemanzav! freemanzav wrote: использует (юзает). В данном случае я говорю о людях, которые используют класс битмапа для разработки. Их вроде даже иногда разработчиками называют :) их называют разработчиками сервера. Прикладной разработчик этот битмап не увидит никогда в жизни (пока исходники сервера не посмотрит). -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"Boltik Evgeny" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > индексу по выражению Так что я думаю это реализуемо. Иначе как же индекс по > выражению живет без "В ключах нет идентификаторов транзакций." А что у нас в выражениях есть ссылки на прочие записи акромя "текущей"?
Re: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
Hello, Evgeny! Boltik Evgeny wrote: Естественно прийдется сделать ссылки на несколько записей по связи. Раз есть какие то механизмы то и то про что я говорю можно реализовать. Ускорение будет в разы на некоторых запросах и упрощение в конструировании таблиц. Сейчас приходится ради индекса и ускорения дублировать поля и строить индекс. Жень, ну ты такое лепишь, я тебе про книжку Тиори и Фрая говорил. какие блин механизмы... к тому же, вычисляемый индекс вычисляет выражение каждый раз, когда изменяется столбец. А если у тебя в выражении охренительный запрос, то значит сервер должен реагировать на изменение записей во всех таблицах такого запроса? Даже если такое и можно было бы сделать, то по производительности это было бы совершенно мертвое решение. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re[2]: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
HV> Ты откуда взялся - с Луны ? :))) Про cooperative vs background gc HV> слыхивал ? Чуточку не согласен, сорри ... ;) Вот вырезка из firebird.conf : # Classic has by default "cooperative" policy. # Other values are ignored by classic server build Или это уже не соответствует действительности и background можно и на класике включить ? С уважением, Константин Григорьевич. ===
Re[2]: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
D> Константин wrote: >> Или это уже не соответствует действительности и background >> можно и на класике включить ? D> А в каком из процессов будем включать background? ;) Дык, а что, нельзя отдельный запустить ? С уважением, Константин Григорьевич. ===
Re[2]: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
Или это уже не соответствует действительности и background можно и на класике включить ? >> >> >> D> А в каком из процессов будем включать background? ;) >> >> Дык, а что, нельзя отдельный запустить ? D> - В сад. D> - Вы будете там петь? D> - Нет, вы будете там слушать. D> (С) : Т.е., как я понял, некому сделать... Типа есть более важные задачи ? Или "это" просто не имеет смысла ? С уважением, Константин Григорьевич. ===
Re[2]: ??N┬?╟?????╣?????╣ Firebird, MysQL ?? PostgreSQL - ?╟N┬
>> Т.е., как я понял, некому сделать... >> Типа есть более важные задачи ? D> Мусик, не нервируй меня (С). На грубость нарываешься. Всё умолкаю ... ;) >> Или "это" просто не имеет смысла ? D> Настолько, что непонятно как такая идея вообще могла зародиться в D> сером веществе. Хоть я и "умолк" :) но всё-же ляпну ... Почему ? PS: За последнее почему готов выдержать побои в виде !беспрекословного! выслушивания ответа на тему: "Почему" ... или тыкания носом в доку где это написано ... PPS: Хе хотелось бы поправлять но в оригинале: "Муля не нервируй меня" - это из фильма ... "Ты Люсь на на грубость нарываешься" - это из песни ... ИМХО, разные веши посему надо 2 копирайта ;) С уважением, Константин Григорьевич. ===
Re: Re[2]: ??NT?│?????│?????│ Firebird, MysQL ?? PostgreSQL - ?│NT
"Константин" ... > >> Или "это" просто не имеет смысла ? > > D> Настолько, что непонятно как такая идея вообще могла зародиться в > D> сером веществе. > > Хоть я и "умолк" :) но всё-же ляпну ... Почему ? Предлагаю всем - перед тем, как что-то предложить или критиковать, подумать - а как это можно сделать иначе, а зачем это нужно делать иначе и почему сейчас это сделанно именно так. -- Хорсун Влад
Re[2]: ??N€?°?????µ?????µ Firebird, MysQL ?? PostgreSQL - ?°N€
Hello Kovalenko, Wednesday, September 20, 2006, 3:52:44 PM, you wrote: KD> Вот скажите мне - через что работают с KD> MSSQL из Delphi ? С ним и с аксесом при необходимости работал через ADO. Тема Дня: Юниксов pазвелось - виндовсу упасть негде. До не скорой встречи в аду, Maxmailto:[EMAIL PROTECTED]
Re: ??NT?�?????�?????� Firebird, MysQL ?? PostgreSQL - ?�NT
> ÃÃÃÃÃÃà ÃÃÃÃÃÃÃà > www.ibase.ru/devinfo/garbage.htm > à > www.ibase.ru/devinfo/sweep.htm > > ÃÃÃà à ÃÃÃÃÃÃà Ãà ÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃà à ÃÃÃà ÃÃà ÃÃà ÃÃ. á ÃÃÃÃÃà ÃÃÃÃÃà Ãà ÃÃà Ãà ÃÃÃÃà âä ÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃà ÃÃÃà ÃÃà Ãà ÃÃÃÃÃà ÃÃÃÃÃÃà Ãà ÃÃÃÃÃÃÃà Ãà ÃÃÃÃÃà ÃÃÃÃÃà à ÃÃÃÃà ÃÃà ÃÃÃÃÃà Ãà ÃÃÃà ÃÃÃÃÃÃÃÃà à ÃÃÃà Ãà ÃÃà ÃÃà Ãà ÃÃà ÃÃÃÃÃÃÃÃÃà à ÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃà à à . îÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃà . òÃÃÃÃà ÃÃÃÃà à ÃÃÃÃÃÃà à ÃÃÃÃÃÃà ÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃà ÃÃÃÃÃà à ÃÃà à Ãà ÃÃÃÃÃà ÃÃÃÃÃà 4 ÃÃÃÃà ÃÃÃÃÃà ÃÃà ÃÃÃÃÃà Ãà ÃÃà ÃÃÃÃÃà ÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃÃÃÃÃ, à à ÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃÃÃÃà Ãà ÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃÃÃÃÃ. é ÃÃà ÃÃÃÃÃà à ÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃà à ÃÃÃÃà ÃÃà à ÃÃà Ãà ÃÃÃÃà ÃÃÃà ÃÃÃÃÃà à ÃÃà à ÃÃà à à Ãà Ãà ÃÃÃÃÃÃÃÃà à ÃÃÃÃÃÃà Ãà ÃÃà ÃÃÃÃÃà à ÃÃÃÃà ÃÃÃà Ãà ÃÃà ÃÃà Ãà ÃÃÃÃà ÃÃà Ãà ÃÃÃà à ÃÃÃÃÃÃÃÃà à ÃÃÃÃÃ. ðÃÃÃÃÃà ÃÃà ÃÃà -housekeeping 100 ÃÃÃÃà Ãà à à à Ãà ÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃ, à à ÃÃà ÃÃÃà ÃÃÃà ÃÃà ÃÃÃÃÃÃÃà :(.
Re: ??NT?�?????�?????� Firebird, MysQL ?? PostgreSQL - ?�NT
>> ÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃà ÃÃÃà ÃÃà Ãà ÃÃÃÃÃà >> ÃÃÃÃÃÃà Ãà ÃÃÃÃÃÃÃà Ãà ÃÃÃÃÃà ÃÃÃÃÃà à ÃÃÃÃà ÃÃà ÃÃÃÃÃà Ãà ÃÃÃà ÃÃÃÃÃÃÃÃà >> à > >îà à ÃÃÃà à à Ãà Ãà ÃÃÃÃÃà Ãà ÃÃà à ÃÃÃÃà - à Ãà ? ó Ãà Ãà ÃÃà Ãà ÃÃà à ÃÃÃÃÃ. óÃÃÃÃà Ãà ÃÃÃÃà Ãà ÃÃà Ãà ÃÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃ. ðÃÃÃÃÃÃà à ÃÃÃà ÃÃà ÃÃà ÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃ. >> ÃÃÃà Ãà ÃÃà ÃÃà Ãà ÃÃà ÃÃÃÃÃÃÃÃÃà à ÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃà à à . > >ôà Ãà Ãà ?! ô.à . Ãà ãà ÃÃÃà âä Ãà ÃÃÃÃÃà à à ÃÃÃÃà ÃÃÃÃÃà ÃÃà ÃÃà ? > ôà Ãà ÃÃÃ-ÃÃÃÃÃà ÃÃÃ... ðÃÃÃà à ÃÃà Ãà ÃÃà ÃÃÃÃ. õ ÃÃÃÃÃà ÃÃÃà ÃÃà ÃÃÃà ÃÃà ÃÃÃÃÃÃà à Ãà ÃÃÃÃà Ãà Ãà Ãà Ãà ÃÃà à ÃÃà à à ÃÃÃÃÃà Ãà ÃÃà à ÃÃÃà . îÃà ÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃà ÃÃà Ãà ÃÃà ÃÃÃ-Ãà Ãà 2004 ÃÃÃ? é ÃÃà ÃÃÃà à ÃÃÃÃÃÃÃà Ãà Ãà 2004 ÃÃÃ? Ã¥ÃÃà à ÃÃÃà ÃÃÃÃà 1 ÃÃÃÃÃà à Ãà ÃÃÃÃÃÃÃà à Ãà 10 Ãà à ÃÃà . îà ÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃà Ãà Ã. >> òÃÃÃÃà ÃÃÃÃà à ÃÃÃÃÃÃà à ÃÃÃÃÃÃà ÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃà ÃÃÃÃÃà à ÃÃà à >> Ãà ÃÃÃÃÃà ÃÃÃÃÃà 4 ÃÃÃÃà ÃÃÃÃÃà ÃÃà ÃÃÃÃÃà Ãà ÃÃà ÃÃÃÃÃà ÃÃÃà ÃÃÃÃà ÃÃÃà >> ÃÃÃÃÃÃ, à à ÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃÃÃÃà Ãà ÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃÃÃÃÃ. é ÃÃà >> ÃÃÃÃÃà >> à ÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃà à ÃÃÃÃà ÃÃà à ÃÃà Ãà ÃÃÃÃà ÃÃÃà ÃÃÃÃÃà à ÃÃà à ÃÃà à à >> Ãà Ãà ÃÃÃÃÃÃÃÃà à ÃÃÃÃÃÃà Ãà ÃÃà ÃÃÃÃÃà à ÃÃÃÃà ÃÃÃà Ãà ÃÃà ÃÃà Ãà ÃÃÃÃà >> ÃÃà Ãà ÃÃÃà à >> ÃÃÃÃÃÃÃÃà à ÃÃÃÃÃ. > >é ÃÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃÃà ÃÃ-ÃÃà ÃÃÃÃà ÃÃÃÃÃà ÃÃÃà "ÃÃÃÃÃÃ" ? á ÃÃà Ãà Ãà à > ÃÃà > Ãà ÃÃÃà Ãà ÃÃÃÃÃÃà Ãà ? óÃÃà ÃÃÃà Ãà à ÃÃÃÃÃÃÃÃÃÃà à à ÃÃÃÃÃÃÃà Ãà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃÃÃÃà Ã.Ã. ÃÃÃÃÃÃÃÃà à ÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃà Ã. >> ðÃÃÃÃÃà ÃÃà ÃÃà -housekeeping 100 ÃÃÃÃà Ãà à à à Ãà ÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃ, à à ÃÃà >> ÃÃÃà ÃÃÃà ÃÃà ÃÃÃÃÃÃÃà :(. > >ó ÃÃÃÃà ÃÃÃÃà Ãà Ãà ÃÃà ÃÃÃà ÃÃÃà ? äÃÃÃÃà ÃÃÃÃÃà Ãà ÃÃÃÃà Ã.Ã. ÃÃÃà Ãà Ãà ÃÃÃÃÃÃÃ. äà à ÃÃÃÃÃà ÃÃà ÃÃà ÃÃÃÃÃÃÃÃà ÃÃÃà Ãà ÃÃÃÃÃÃÃà ÃÃà ÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃÃà Ãà ÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃà Ãà ÃÃÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃ. > PS ñ ÃÃà ÃÃÃÃÃà _ÃÃÃÃÃÃÃ_ ÃÃÃÃÃÃ, à _ÃÃÃÃÃ_ ÃÃÃÃÃà á ÃÃà ÃÃÃÃÃà ÃÃà à Ãà ÃÃÃÃÃ? ñ ÃÃÃÃÃÃÃà Ãà ÃÃà à Ãà ÃÃà ÃÃà ÃÃÃÃÃà ÃÃà à ÃÃà ÃÃÃà ÃÃà ÃÃÃÃÃ. é ÃÃà Ãà Ãà Ãà ÃÃÃÃÃÃà à Ãà ÃÃà ÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃà ÃÃ. ðÃÃÃÃÃà ÃÃà ÃÃÃÃÃà ÃÃÃà Ãà Ãà ÃÃà ÃÃÃÃÃÃÃ. ñ à ÃÃà ÃÃÃÃÃÃÃà ÃÃà ÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃ. > PPS ôÃÃÃà à ÃÃÃÃÃ, ÃÃà ÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃ, ÃÃÃà Ãà Ãà ÃÃÃÃà ÃÃà > âä, >ÃÃà à ÃÃà à ÃÃÃÃà à ÃÃà Ãà ÃÃÃÃà Ãà ÃÃÃÃÃÃÃÃà à 3.0. >ðÃÃÃÃÃÃÃÃÃÃÃÃà Ãà ÃÃÃÃÃà Ãà ÃÃ, ÃÃà îà Ãà ÃÃà ÃÃÃÃÃÃÃà ñ ÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃ, Ãà ÃÃÃÃà à ÃÃà Ãà à Ãà à ÃÃÃà à ÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃÃÃà ÃÃÃÃÃà à ÃÃà ÃÃÃÃÃà ÃÃÃÃÃ. ðÃÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃà ÃÃà ÃÃÃ. äÃà ÃÃà à ÃÃà ÃÃÃÃà ÃÃà ÃÃÃÃÃÃÃà ÃÃÃà Ãà ÃÃÃÃÃÃ. óà ÃÃÃà ÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃà ÃÃÃÃÃÃÃÃà ÃÃÃà ÃÃà à computed by ÃÃÃÃÃÃÃÃ. é ÃÃà à ÃÃà 2 ÃÃÃÃÃÃà T1 F1 F2 T2 F1 F3 à ÃÃà ÃÃÃÃà V1 F1, F2, F3 from T1, T2 where T1.F1 = T2.F1 à Ãà Ãà Ãà ÃÃÃÃÃÃÃà à ÃÃÃÃà ÃÃÃÃÃà select * from V1 where F2 = x and F3 = y Ãà à ÃÃà ÃÃÃà ÃÃà ÃÃÃÃÃÃÃÃÃÃà à ÃÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃà à Ãà ÃÃÃÃÃÃÃÃÃà Ãà ÃÃÃÃÃÃà T1 ÃÃÃÃà Ãà ÃÃÃÃÃà ÃÃà ÃÃà à ÃÃà Ãà Ãà Ãà ÃÃÃÃà à Ãà ÃÃÃÃÃà à à ÃÃÃÃÃÃÃà ÃÃÃà Ãà CREATE INDEX idx2 ON T2 ( (select F2 from T1 where T1.F1 = T2.F1) [as F2], F3) à ÃÃà ÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃà ÃÃÃÃ
Re: ??NT?�?????�?????� Firebird, MysQL ?? PostgreSQL - ?�NT
äÃÃÃà Ãà Ãà Ãà ÃÃà ÃÃÃÃà ÃÃà Ãà Ãà ÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃà à ÃÃÃÃà à Ãà ÃÃÃÃÃÃà à ÃÃà Ãà Ãà Ãà ÃÃÃÃÃà ÃÃÃ. 1.Ã¥ÃÃà Ãà Ãà ÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃà à ÃÃÃÃà Ãà Ãà Ãà ÃÃà à ÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃà ÃÃà ÃÃÃÃÃà ÃÃà ÃÃÃÃÃÃÃÃ. îà ÃÃÃÃÃÃà ÃÃÃÃà à à Ãà ÃÃÃ. ÃÃÃÃÃà à à Ãà ÃÃà select * from t1, t2, ts where ts.fs = :P1 and ts.prod = t1.prod and t1.pok = :pok and t1.id = t2.t1id and t2.kolvo > 0 ÃÃÃÃÃÃà à ÃÃÃÃÃà Ãà à à ÃÃà ÃÃÃà prod, pok ÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃÃÃÃà à t2 Ãà à ÃÃà ÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃà Ãà ÃÃà select * from t2, ts where ts.fs = :P1 and ts.prod = t2.prod and t2.pok = :pok and t2.kolvo > 0 Ãà Ãà Ãà à ÃÃà ÃÃÃà ÃÃà à ÃÃÃÃÃà ÃÃÃà Ãà à t2 = prod, pok, kolvo à ÃÃÃÃÃÃà ÃÃÃÃà Ãà ÃÃÃà Ãà ÃÃÃÃÃÃà à Ãà Ãà Ãà Ãà ÃÃÃÃÃÃà à ÃÃÃÃÃà ÃÃÃÃÃà à ÃÃÃÃÃÃà à à ÃÃÃà ÃÃÃÃ. ðÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃà ÃÃÃà ÃÃà Ãà ÃÃà ÃÃÃÃÃà ÃÃÃÃà ÃÃà ÃÃà ÃÃÃÃÃÃà T2 Ãà T1. îà ÃÃÃÃà à Ãà Ãà Ãà ÃÃÃà ÃÃÃÃÃÃà à ÃÃÃÃÃÃà ÃÃÃà ÃÃà Ãà ÃÃÃ. Ã¥ÃÃà ÃÃà ÃÃÃà ÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃà à prod, pok à t2 à ÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃà ÃÃà CREATE INDEX idx2 ON T2 ( (select prod from T1 where t1.id = t2.t1id) [as prod], (select pok from T1 where t1.id = t2.t1id) [as pok], kolvo) à ÃÃÃÃÃà ÃÃÃà à prod, pok à t2 Ãà ÃÃÃÃà à Ãà ÃÃà ÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃÃà à ÃÃÃà ÃÃÃà ÃÃà à ÃÃÃÃÃà ÃÃ. á ÃÃÃÃÃà à ÃÃÃÃÃÃà select * from t1, t2, ts where ts.fs = :P1 and ts.prod = t1.prod and t1.pok = :pok and t1.id = t2.t1id and t2.kolvo > 0 ÃÃÃà à ÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃÃà ÃÃÃà Ãà idx2 ÃÃà ÃÃÃÃà ÃÃÃÃÃà à ÃÃÃÃÃÃÃà Ãà Ãà ÃÃÃÃÃà Ãà Ãà Ãà ÃÃà ÃÃÃÃÃÃà à ÃÃà à ÃÃà ÃÃÃÃÃÃÃà CREATE INDEX idx2 ON T2 ( (select prod from T1 where t1.id = t2.t1id) [as prod], (select pok from T1 where t1.id = t2.t1id) [as pok], kolvo) Ãà à ÃÃÃÃÃÃà T1 ÃÃÃÃà à ÃÃÃà ÃÃÃÃÃà à Ãà ÃÃÃà ÃÃÃÃÃÃà ÃÃà T2 Ãà t1.id = t2.t1id Ã.Ã. ÃÃÃÃÃà à ÃÃÃà ÃÃà ÃÃÃà ÃÃÃÃÃÃÃà à ÃÃà ÃÃÃà prod, pok à t1 ÃÃÃà ÃÃÃÃÃà à Ãà Ãà ÃÃÃÃÃÃÃÃà à ÃÃà ÃÃÃà ÃÃà ÃÃÃÃÃà Ãà Ãà ÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃà Ãà ÃÃÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃà Ãà CREATE INDEX idx2x ON Tx ( (select T1.prod from T1, t2 where t1.id = t2.t1id and t2.id = tx.t2id) [as prod], (select T1.prod_sk from T1, t2 where t1.id = t2.t1id and t2.id = tx.t2id) [as prod_sk], (select T1.pok from T1, t2 where t1.id = t2.t1id and t2.id = tx.t2id) [as pok], (select T2.kolvo from T2 where t2.id = tx.t2id) [as kolvo] ) ÃÃà ÃÃÃà à ÃÃÃÃÃÃà ÃÃÃÃÃÃÃà à ÃÃÃÃÃÃà ÃÃÃÃà Ãà ÃÃÃà à ÃÃà ÃÃÃà ÃÃà ÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃà ÃÃÃà ÃÃà Ãà ÃÃÃà ÃÃÃÃÃÃÃÃÃà Ãà ÃÃà à ÃÃÃÃÃà à à ÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃ. õ ÃÃà Ãà ÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃà à ÃÃÃÃà à à Ãà Ãà à Ãà Ãà ÃÃÃà ÃÃÃÃà à ÃÃÃÃà ÃÃà à ÃÃà à ÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃà Ãà ÃÃà ÃÃà ÃÃÃÃÃÃà ÃÃÃÃÃÃà à Ãà Ãà Ãà ÃÃà Ãà ÃÃà Ãà ÃÃà à Ãà Ãà ÃÃà ÃÃÃÃÃÃà à ÃÃà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃà ÃÃÃÃÃÃà ÃÃà ÃÃÃÃÃÃà ÃÃÃÃÃà Ãà à ÃÃÃÃÃÃà ÃÃÃà à ÃÃÃà ÃÃÃÃÃÃÃ. îÃÃÃÃÃÃÃà à ÃÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃÃà Ãà ÃÃÃÃÃÃÃÃÃà ÃÃÃà ÃÃÃà à ÃÃÃÃà ÃÃÃÃà ÃÃà Ãà ÃÃÃà ÃÃÃà ÃÃÃà Ãà ÃÃÃÃÃÃà à ÃÃÃÃÃà ÃÃÃÃÃà à ÃÃà ÃÃÃÃÃÃÃà à Ãà Ãà ÃÃÃÃÃÃÃÃà à ÃÃÃà ÃÃÃà ÃÃÃÃÃà à ÃÃÃÃÃÃà à Ãà ÃÃÃÃÃÃÃ. õ Ãà Ãà à ÃÃÃÃà Ãà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃà 7 ÃÃÃà à à ÃÃÃÃà ÃÃÃÃÃÃà à ÃÃÃÃÃà Ãà ÃÃÃà à ÃÃÃÃÃà ÃÃÃà ÃÃÃÃÃÃÃà ÃÃÃà ÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃà Ãà Ãà ÃÃÃÃÃÃ. èÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃà à ÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃà à Ãà ÃÃÃÃÃÃÃà ÃÃÃà Ãà Ãà Ãà ÃÃÃÃà à ÃÃÃà ÃÃà ÃÃÃÃÃà Ãà ÃÃà ÃÃÃà 400 ÃÃ. ñ ÃÃÃÃÃÃà ÃÃà 30% ÃÃÃÃÃÃÃà ÃÃà ÃÃÃÃÃÃà Ãà ÃÃÃÃà ÃÃÃÃÃÃÃà ÃÃà ÃÃÃà à ÃÃÃÃÃÃÃÃÃà Ãà ÃÃÃà FK ÃÃÃÃ
Re: ??NT?�?????�?????� Firebird, MysQL ?? PostgreSQL - ?�NT
>> îà ÃÃÃÃà à Ãà Ãà Ãà ÃÃÃà ÃÃÃÃÃÃà à ÃÃÃÃÃÃà ÃÃÃà ÃÃà Ãà ÃÃÃ. Ã¥ÃÃà ÃÃà ÃÃÃà >> ÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃà à prod, pok à t2 à >> ÃÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃà ÃÃà >> CREATE INDEX idx2 ON T2 ( >> (select prod from T1 where t1.id = t2.t1id) [as prod], >> (select pok from T1 where t1.id = t2.t1id) [as pok], >> kolvo) > > öà ÃÃ, ÃÃà ÃÃÃÃà Ãà ÃÃÃà Ãà ÃÃÃÃÃÃÃà ÃÃà Ãà ÃÃÃÃÃÃÃ, à ÃÃÃÃÃÃÃÃÃÃÃ. > ÷ ÃÃÃÃÃà Ãà à ÃÃà ÃÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃ. óÃÃÃÃÃà à ÃÃà Ãà ÃÃÃÃà ÃÃÃà Ãà Ãà Ãà ÃÃà ÃÃÃà ÃÃÃÃà ÃÃà ÃÃà . óÃÃÃÃÃà à à Ãà ÃÃÃÃÃà ÃÃÃà à à ÃÃÃÃÃÃÃÃà ÃÃÃÃà ÃÃà ÃÃÃÃÃà à æâ, Ãà ÃÃà Ãà ÃÃÃÃÃÃÃà ÃÃà à à ÃÃÃÃÃÃà ÃÃÃÃà ÃÃÃà Ãà ÃÃÃà ÃÃÃÃÃ. ëÃÃÃà à ÃÃÃÃà ÃÃÃà ÃÃÃÃÃÃÃÃà à Ãà ÃÃÃÃà ÃÃÃÃÃÃÃà à ÃÃÃÃà Ãà ÃÃÃÃÃÃÃÃÃÃà Ãà Ãà ÃÃÃÃ. óÃÃÃÃÃà ÃÃà ÃÃÃà ÃÃÃÃà Ãà ÃÃÃÃÃÃÃÃ. ðÃÃÃà ÃÃÃÃà Ãà ÃÃà ÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃ. ðÃÃà ÃÃÃà Ãà ÃÃÃÃÃà ÃÃÃÃà Ãà ÃÃÃÃÃÃÃÃ. >> á ÃÃÃÃÃà à ÃÃÃÃÃÃà >> select * from t1, t2, ts where >> ts.fs = :P1 and >> ts.prod = t1.prod and >> t1.pok = :pok and >> t1.id = t2.t1id and t2.kolvo > 0 >> >> ÃÃÃà à ÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃÃà ÃÃÃà Ãà idx2 ÃÃà ÃÃÃÃà > > à ÃÃÃÃÃà Ãà à Ãà ÃÃÃà ÃÃÃÃÃà à ÃÃÃÃÃÃà t1 Ãà ÃÃÃà ÃÃÃà à > ÃÃÃÃÃÃÃÃÃÃ, ÃÃÃÃà ÃÃà ÃÃà ÃÃÃÃà ÃÃà ÃÃÃÃà ÃÃÃÃÃÃÃÃà > à ÃÃÃÃÃà ÃÃÃà Ãà ÃÃÃà ÃÃÃÃÃà à t2. ëÃà ÃÃà Ãà ÃÃÃà ÃÃÃÃà Ãà ÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃà ÃÃÃÃÃ.
Re: ??NT?�?????�?????� Firebird, MysQL ?? PostgreSQL - ?�NT
"Dmitry Yemanov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > ðÃÃÃÃÃÃà ÃÃÃÃÃÃ, Ãà ÃÃÃÃÃà :-) ôÃÃÃà ÃÃÃÃÃÃà :-) óÃÃà ÃÃÃÃÃà , "1.1.1. ðÃÃÃÃà ÃÃÃÃÃÃÃÃ_ÃÃà " -- ÃÃÃÃÃÃÃÃÃÃÃà , ÃÃÃÃÃÃà Ãà "Ã" ÷Ãà Ãà ÃÃà , 1-à ÃÃÃ. 2-à ÃÃà ÃÃ."ÃÃÃÃà ÃÃÃÃ_ÃÃÃÃÃÃÃÃ" -- ÃÃÃÃÃÃÃÃÃÃÃÃÃ, ÃÃÃÃÃÃà Ãà "Ã" ÃÃà Ãà , 4-à ÃÃÃ., ÃÃÃÃÃà "ÃÃÃÃÃà ÃÃÃÃ_ÃÃÃÃÃÃÃà Ã" -- ÃÃÃÃÃÃÃÃÃÃÃÃà Ã, ÃÃÃÃÃÃà Ãà "Ã" 1.2.2., 3-à ÃÃà ÃÃ. "ÃÃÃÃÃÃÃÃÃÃÃà à ÃÃ_ÃÃÃÃÃÃ" -- ÃÃÃÃÃÃÃÃÃ, ÃÃÃÃÃÃà Ãà "Ã" ÃÃà Ãà , ÃÃà ÃÃÃÃ. ÃÃà ÃÃ. "Ãà ÃÃà _à Ãà ÃÃ" -- ÃÃà à Ã, ÃÃÃÃÃÃà Ãà "à " 2.6., 1-à ÃÃÃ, 1-à ÃÃà ÃÃ. "Ãà ÃÃÃÃ_à _ÃÃÃÃà ÃÃÃÃ" -- Ãà ÃÃÃÃÃÃÃÃÃà ÃÃÃÃ, à /à 3.1.2., 6-à ÃÃÃ., "ÃÃ_Ã_à ÃÃÃà ÃÃÃÃ" -- ÃÃÃà ÃÃÃà ÃÃÃÃ, Ã/à ÃÃà Ãà "ÃÃ_Ã_à ÃÃÃà ÃÃÃ" -- ÃÃÃà ÃÃÃà ÃÃÃ, Ã/à ÃÃà Ãà , ÃÃÃÃ. ÃÃÃ. "ÃÃÃÃÃÃÃÃÃÃ_à à ÃÃà ÃÃà à ÃÃà ÃÃÃà ÃÃà " -- ÃÃÃÃÃÃÃÃÃÃÃà à , ÃÃÃÃÃÃà Ãà "Ã" úÃÃÃÃÃà ÃÃà , 2-ÃÃÃ, "Ãà Ã_Ã_ÃÃÃÃÃÃÃ" -- Ãà ÃÃÃÃÃÃÃÃÃ, Ã/à -- wbr, sb
Re: ??NT?�?????�?????� Firebird, MysQL ?? PostgreSQL - ?�NT
>>> CREATE INDEX idx2 ON T2 ( >>> (select prod from T1 where t1.id = t2.t1id) [as prod], >>> (select pok from T1 where t1.id = t2.t1id) [as pok], >>> kolvo) >> >> öà ÃÃ, ÃÃà ÃÃÃÃà Ãà ÃÃÃà Ãà ÃÃÃÃÃÃÃà ÃÃà Ãà ÃÃÃÃÃÃÃ, à ÃÃÃÃÃÃÃÃÃÃÃ. >> ÷ ÃÃÃÃÃà Ãà à ÃÃà ÃÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃ. îà ÃÃÃÃà ÃÃÃÃÃÃà ÃÃÃÃÃÃÃà Ãà ÃÃÃÃÃÃà ÃÃà ÃÃÃÃ. üÃà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃà ÃÃÃà ÃÃà Ãà ÃÃÃÃÃà ÃÃà ôÃà ÃÃà à ÃÃÃÃà ÃÃà Ãà ÃÃÃÃÃà ÃÃ. éÃÃÃà ÃÃà Ãà ÃÃÃà Ãà Ãà ÃÃÃÃÃà ÃÃà ÃÃÃà à Ãà à "÷ ÃÃÃÃÃà Ãà à ÃÃà ÃÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃ."
Re: ??NT?�?????�?????� Firebird, MysQL ?? PostgreSQL - ?�NT
"Oleg LOA" <[EMAIL PROTECTED]> ÃÃÃÃÃÃÃ/ÃÃÃÃÃÃÃà à ÃÃÃÃÃÃÃà ÃÃà ÃÃÃÃà à : news:[EMAIL PROTECTED] > "Boltik Evgeny" <[EMAIL PROTECTED]> wrote in > message news:[EMAIL PROTECTED] >> ÃÃÃà ÃÃà Ãà ÃÃÃÃÃà ÃÃà ôÃà ÃÃà à ÃÃÃÃà ÃÃà Ãà ÃÃÃÃÃà ÃÃ. éÃÃÃà ÃÃà Ãà ÃÃÃà Ãà >> Ãà >> ÃÃÃÃÃà ÃÃà ÃÃÃà à Ãà à "÷ ÃÃÃÃÃà Ãà à ÃÃà ÃÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃÃÃÃÃ." > > á ÃÃà à ÃÃà à ÃÃÃÃÃà ÃÃÃà à ÃÃà ÃÃÃÃÃà Ãà ÃÃÃÃÃà ÃÃÃÃÃà ÃÃÃÃÃà "Ãà ÃÃÃà Ã"? Ã¥ÃÃà ÃÃÃà ÃÃà ÃÃÃÃÃà ÃÃà ÃÃà ÃÃÃà ÃÃÃÃÃà Ãà Ãà ÃÃÃÃÃÃà ÃÃÃÃÃà à Ãà ÃÃÃÃÃ. òÃà à ÃÃà ÃÃÃÃà Ãà Ãà ÃÃÃÃÃÃà Ãà à Ãà ÃÃà ÃÃà à ÃÃÃÃÃà ÃÃÃÃà Ãà ÃÃÃÃÃÃÃÃÃ. õÃÃÃÃà ÃÃà ÃÃÃà à à ÃÃÃà Ãà Ãà ÃÃÃÃÃÃà ÃÃÃÃÃÃÃà à ÃÃÃÃÃà ÃÃà à ÃÃÃÃÃÃÃÃÃÃÃÃÃÃà ÃÃÃÃÃÃ. óà ÃÃÃà ÃÃÃÃÃÃÃÃÃà ÃÃÃà ÃÃÃà ÃÃà à ÃÃÃÃÃà ÃÃà ÃÃÃÃÃÃÃÃÃÃà ÃÃÃà à ÃÃÃÃÃÃà ÃÃÃà ÃÃ.
