Re: сколько может стоить
Andrew пишет: это небольшое производство. двигатели для электричек и поездов. Дочка силоввых машин. Просто была у них проверка. а у них бардак со списанием материалов в производство. поэтому сверху сказали - надо сделать позаказный учет себестоимости. Тем более что у них ципл производства довольно большой. Посмотрите стоимость УПП. Добавьте еще столько же на доработку под местные нужды. Получите оценку системы с потолка. Ну, еще умножьте на случайный коэффициент 2, дабы получить вероятную стоимость внедрения в вашем случае.
Re: OFF: Кто как подтягивает курсы валют из инета?
http://www.cbr.ru/scripts/XML_daily.asp
Re: OFF: Delphi 2007 Enterprise Trial
Начинаю чувствовать себя безнадежно отставшим от жизни - замерли на Delphi 6. Последнее, что устанавливал на посмотреть - Delphi 7. А смысл есть?
Re: OFF: Delphi 2007 Enterprise Trial
Boulitchev Aleksey пишет: с 6-ки на 7-ку смысл был. Не нашел там ничего нового кроме Web-технологий. А смена версии среды разработки на работающем проекте - достаточно болезненная операция.
Re: off: лицензия
Ded пишет: По поводу проверок и прочего... В тему: http://sysadmin.mail.ru/pforum/viewtopic.php?t=7746 Вот любопытно, вся эта шумиха вызовет рост популярности альтернативного ПО?
Re: фотоотчет с конференции
dada sasa пишет: А был ли Ded на конференции? Сдается, что не был... А? Колоритная фигура должна быть :) А почему это тебя интересует фигура Деда? :)))
Re: архив конференции
Nikolai Voynov пишет: Если у кого есть архив конференции помогите пожалуйста. http://groups.google.ru/group/ru-firebird?lnk=sghl=ru
Re: OFF Oracle
DmitryLe пишет: Нужны компоненты прямого доступа. Зачем? Доступ универсальными способами (ADO, ODBC, dbExpess etc) чем не устраивает? Потом же легче будет, когда появится схожая задача под FB или что угодно.
Re: Yaffil = FB2
arni пишет: 1) Агрегатная функция LIST. Документирована ли она стандартом SQL Нет и намечается ли к реализации? http://www.firebirdsql.org/index.php?op=devjournalid=djarchiveno_rss=1 См. от 1 мая 2006 года.
Re: OFF: Мы все умрем ?
Первоисточник этой инфы - сайт www.kometa.by.ru сегодня удален пару часов назад. Наверное чтобы предотвратить распространение паники :)
Re: Borland's Developer Tools Group Introduces InterBase 2007
MSSQL начал, IB продолжил. Интесно, кто следующий сбросит нормальную нумерацию версий и пойдет стопами вин95?
Re: Borland's Developer Tools Group Introduces InterBase 2007
Однако Write Ahead Logging (WAL) technology. В IB отказались от того преимущества, которым тут эпизодически хвалились :)
Re: Borland's Developer Tools Group Introduces InterBase 2007
Dmitry Yemanov пишет: В IB отказались от того преимущества, которым тут эпизодически хвалились :) Сарказм не к месту. Я бы не стал затаивать дыхание насчет их реализации. Да не сарказм это. Хотя, может и сарказм, но точно не в твой адрес. А чудес от их реализации давно не жду. Как-то сделали, как-то возможно работает. Почему бы и нет? SMP ведь как-то все-таки осилили, даже по TPC-C в ibdeveloper местами вперед вырвались. А последние их чудеса на моей памяти - это Delphi 1 и C++ Builder. Вот это было круто! Вот на это дыхание затаивалось и за такое даже баги прощались. Хотя, может просто моложе тогда был. Тем не менее, робкие мысли а не плохо бы лог... шепотом эпизодически возникают тут и на sql.ru. Совсем недавно было. Есть планы? P.S. А тем временем PG 8.2 бета вышла...
Re: Шифрование БД
Horsun Vlad пишет: Т.к. желающие обсудить нашлись, то вот и предмет обсуждения. Было ещё одно письмо с обоснованием необходимости шифрования и возникающими проблемами \ требованиями, но оно пока не переведено на русский. Если возникнет необходимость, выложу и его. Хотя бы в двух словах: под что это? Те самые распространяемые БД на CD? д) движок: KeyAuthClosed = Decrypt(KeyAuthClosed_enc, KeySessionClosed) KeyDB = Decrypt(KeyDB_enc, KeyAuthClosed) Движок - в смысле FB? Основная цель такого алгоритма: никто не должен иметь доступ к расшифрованным ключам - ни приложение, ни движок, ни канал передачи. Это как сочетается с пунктом Д? Немножко не понял, как в этой схеме организуется многопользовательская работа. Все клиенты обязаны авторизовываться? В какой момент делается расшифровка страницы? В каком виде она попадает в кэш?
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Eugene пишет: Классик - в печку. Руки прочь от классика! Классик должен вымереть - это тупиковая ветвь эволюции. SS надо до ума доводить. Сам ты тупиковая ветвь. Чего наехали на человека? Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad пишет: Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Причём тут кеш к архитектуре ? Может и ни при чем. Но такая вот особенность в FB CS имеется. Ну будет он шариться и шо ? Ты сразу полюбишь классик ? Не сразу, а медленно и постепенно :) Так он и так шарится - через кеш FS :))) А мог бы шариться еще эффективнее и умнее. Со всякими там новомодными методиками вытеснения страниц, с опцией cache warming для особых эстетов и т.п. Кстати, если рассматривать потенциальную возможность того, что в FB будет шифрование, то в таком варианте кэш FS ну никак не поможет. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет. Не вымрет. Хотя бы потому, что это полуготовое кластерное решение Ну, в общем-то с таким вариантом и с доводом надежности не поспоришь. Да собственно против архитектуры я ничего не имею. Я имел в виду именно сочетание распараллеливания и общего кэша.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitry Yemanov пишет: всякими там новомодными методиками вытеснения страниц Которые постгрес который год тасует в попытках убежать от патентного права :-) Тяжелый случай. Способ потребления кислорода человеком под названием дыхание случайно никто еще не запатентовал? Надо бы подсуетиться...
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitri Kuzmenko пишет: Поэтому впечатление такое, что поскольку ликвидировать мифы об IB/FB невозможно, нужно просто запускать похожие факты-мифы о других серверах. Про платность MySQL под GNU - из того же разряда? ;) не gnu, а gpl. и не платность под gpl, и т.п. И вообще, сказал А, говори Б. Да мне MySQL с его лицензией побоку. Я с ним сталкиваюсь только на хостинге либо в приходящих резюме с перлами типа Разрабатываю в свободное время программу бухучета типа 1с на Delphi+MySQL 3 :) Я просто сопоставил твою активность в форумах на эту тему и предложение запуска факто-мифов P.S. А вообще, конечно, MySQL напирает. Огромная армия веб-мастеров переквалифицируясь с написания гостевых книг на системы учета тянет за собой этот самый чудо-сервер, ибо других не знают. Ладно бы еще PostgreSQL... Хотя сведения о MySQL у меня застыли на 3-й версии. Может с 5-й он и правда так крут, каким пытается казаться?
Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Вот скажите мне - через что работают с MSSQL из Delphi ? Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом кажется гораздо меньше заморачиваются по родным компонентам прямого доступа.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом кажется гораздо меньше заморачиваются по родным компонентам прямого доступа. Вот и я абсолютно о том же. Но у нас упорно - это типа у нас нативе, а это у нас как у вас. Первое у нас быстрее и все такое. Интересно - откуда конкретно такая уверенность? И это продолжается до сих пор. Есть такое. Дед, конечно, прав, кто как хочет, так и... Но вот свежайший пример навскидку: http://sql.ru/forum/actualthread.aspx?tid=340299#3159886 Все советуют native. Все рассказывают про какие-то лишние тормоза, как будто дополнительные микросекунды на вызов могут сказаться при разработке массовых бизнес-приложений. Но напомни, плиз, если я скачаю дистрибутив FB, там в комплекте будут ODBC и OLE DB драйверы? Судя по http://ibase.ru/components.htm - нет, не будут. Вижу там 5 разных драйверов ODBC, 3 штуки OLE DB. А оно надо - так много? Заморачиваться, выбирать, пробовать. Ах, еще и платить надо? У PG8 в этом плане проще и понятнее. ODBC драйвер в дистрибутиве есть. OLEDB есть. Хоть про второй инсталлятор и предупреждает честно, что он еще сырой, но тем не менее он есть и понятна политика: он, очевидно, будет и в дальнейшем. И не надо ничего искать и выбирать. А такое разнообразие одних только ODBC драйверов наводит на мысль, что это не от хорошей жизни. Чисто интуитивно напрашивается мысль: пишут все кому не лень, потому что не устроило то, что нашли. А были бы эти драйвера в комплекте, многие и не заморачивались бы больше ничем. А про Delphi мысль непонятна. Что значит оторвать? Оторвать то, может, и легко, только не забывай, что FB своей популярностью в основном обязан именно Delphi. По крайней мере в России.
Re: OFF: A SQL Server Everywhere щупал кто?
Konstantin R. Beliaev пишет: Ты про Sybase? Вот она, четкая ассоциация! Anywhere - Everywhere. MS решила урвать кусок рынка мобильных юзеров у SQL Anywhere и пошла по пути производителей кроссовок ABIBAS, REBOOK и т.п. :) Это майкрософтовский сервер, по инфомации из третьих рук вроде SQL Mobile, которого сделали inprocess - сервером (как FB embedded), и внесли некоторые косметические изменения, самое главное из которых - переименование. http://www.microsoft.com/downloads/details.aspx?familyid=85e0c3ce-3fa1-453a-8ce9-af6ca20946c3displaylang=en Даже Windows 2000 не поддерживает. Воистину Everywhere :)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitri Kuzmenko пишет: Поэтому впечатление такое, что поскольку ликвидировать мифы об IB/FB невозможно, нужно просто запускать похожие факты-мифы о других серверах. Про платность MySQL под GNU - из того же разряда? ;)
Re: Firebird, MysQL PostgreSQL
veliks пишет: Но, отходя вв сторону от сути вопроса, лично ятак и не понял 1С , чем им не угодил Sybase.И бесплатные версии есть, и под линухом работает, Вот именно! Бесплатные версии ASE есть только под Linux. А маленькие фирмочки, на которые позиционируют постгресовскую версию 1с, могут и не иметь в штате админа, который в состоянии сопровождать линух, да еще и с ASE на борту. А так они выбрали не самую распространенную СУБД Распространенность понемногу растет после выхода pg8 под win, а с 1с вырастет еще заметнее.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Oleg Deribas пишет: Это не я не читаю, это ты не читаешь ;) Нет, это ты не понял. Это просто анти-PR акция. Ход, практикуемый адвокатами или обвинителями в судах с присяжными - выдать какую-либо информацию, которую может и не пришьют к делу, но осадочек в умах присяжных останется, который потом может повлиять на решение при сомнениях :)
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: Поэтому использование программного raid при наличии аппаратного - #$%#%$#. Аппаратный raid позволяет сделать зеркалирование не дисков целиком, а выбранных разделов? нет. А смысл? Я на серверы самого начального уровня (для мелких филиалов) обычно ставлю два SATA диска. Зеркалируется система и раздел с критичными данными. И остается еще два крупных раздела под всякий хлам, смысла в зеркалировании которого не вижу. Давайте так - я считаю программный raid бессмыслицей, несмотря на письмо Артура Галимова. Т.е. как я и предположил, это из области личных пристрастий, которые нет большого смысла обсуждать. Вполне понятно и естественно - у многих есть подобные предубеждения по разным вопросам, имеющим несколько относительно равноценных решений.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
ArtGal пишет: Диски в raid дохнут чаще. За 4 года сдохло 4 сказика, IDE и SATA - десятка полтора. Из скольки? А то это похоже на статистику угоняемости. Оказывается, самый угоняемый - ВАЗ чего-то там, хотя угоняют небось единицы машин на сотню. А какая-нибудь редкая марка, которой угнали лишь две штуки, но из всего 3-х имевшихся в стране, попадает вниз рейтинга угонов.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: какой бы ни был, программный raid не имеет смысла, потому что сейчас любая самая задрипанная материнская плата имеет встроенную поддержку raid 0 и 1 на аппаратном уровне. Поэтому использование программного raid при наличии аппаратного - #$%#%$#. Аппаратный raid позволяет сделать зеркалирование не дисков целиком, а выбранных разделов?
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: В любом случае, программный raid - это мазохизм :-) Это почему? raid-5 средствами ОС - может и мазохизм, не знаю. А вот raid 0 и 1 иногда очень удобны для некоторых применений. Впрочем, что я тебе рассказываю? Из твоей же статьи http://www.ibase.ru/devinfo/raid.htm RAID 0 - для монтажа видео - самое то, что надо. Надежность роли не играет, если о ней помнить и хранить бэкапы где надо. А RAID 1 средствами ОС - IMHO идеальное решение для недорогих серверов, например для мелких филиалов. Чем плохо то? Просвети, плиз.
Re: Обрывы соединения
Константин пишет: Так тот что 3-шник хоть что-то на FoxPro лабает (правда выглядит ужастно - но кое как работает, видать всё-таки научился), а отличник, каким-то образом, сразу в управленческое звено пролез. И хоть со времёт учёбы ни строчки не написал - но с успехом раздаёт ТЗ, и погоняет наших ... А я, как говорится, у разбитого корыта ... И где, спрашивается, правда ? А это и есть правда, как это ни было бы печально и неприятно для тебя. Если ты хорошо рисуешь дипломы, то почему из этого должно следовать то, что ты хороший управленец и в состоянии раздавать ТЗ и погонять ваших? Гораздо более логичным и естественным на месте управленца выглядит тот самый отличник, который умудрился грамотно организовать процесс: за копейки (скорее всего) поручил тебе рисовать диплом и получил результат, сэкономив свое время на что-нибудь более интересное для себя. Ничего личного, но СССР тут ни при чем.
Re: OFF: любопытно
http://sql.ru/forum/actualthread.aspx?tid=328662
Re: Select из двух баз
Alexandr Kochmin пишет: через MSAccess еще можно ;) Тогда уж и через любой сервер БД, поддерживающий гетерогенные запросы :)
Re: Все помнят что с понедельника финал?
Kovalenko Dmitry пишет: Объясните глупому, КАК МЕНЬШЕ ЧЕМ ЗА ЧАС проголосовало больше 3 штук. Это реально или там что-то сломалось? 8-) Судя по database not started! - сломалось. А 3 тысячи - это не за час. Это они скорее всего хотели сразу приплюсоватьмаксимальные результаты прошедших недель, чтоб люди не напрягались суммированием. По условиям конкурса победитель считается по сумме голосов за этоту неделю плюс лучший результат за прошедшие.
Re: Все помнят что с понедельника финал?
Может с форума MSSQL и будут голоса, но комменты там, мягко говоря, жлобские :( Менталитет совка: беда не в том, что у меня корова сдохла, а в том, что у соседа жива осталась...
Re: OFF: посоветуйте CVS для небольшого коллектива (Delphi 7)
http://sql.ru/forum/actualthread.aspx?tid=305829
Re: Версия БД, или как отсделить изменения метаданных ?
Константин пишет: Cобственно SUBJ. Есть ли такая фишка ? Для какой цели интересуешься? Если для перенесения изменений из девелоперской БД в боевую или что-то вроде того, то IMHO самый оптимальный вариант - организационный. Обеспечить внесение изменений даже в тестовые базы исключительно только через SQL с обязательным протоколированием. Пришел к этому варианту после перепробованного множества других: сравнение через Power Designer, сравнение выгруженных скриптов в WinDiff, собственный инструментарий сравнения, вычленение изменений через transaction log (не для FB) и т.п. В конечном итоге родилась простейшая БД, фиксирующая все скрипты модификации, в которой для каждой модификации фиксируется, к каким БД она уже приложена. При большом кол-ве сопровождаемых баз лучшего варианта не вижу.
Re: Версия БД, или как отсделить изменения метаданных ?
(В догонку) И параллельно с этим, то, что скорее можно отнести к коду, чем к метаданным (процедуры, функции, view, триггеры) хранится еще и в системе контроля версий. При этом в тело автоматом вставляются комментарии типа такого: --$Revision:1.9$ --$RevDate:28.04.2006 17:20:16$ --$Author:alexgold$
Re: Офф. Дико извиняюсь. Но.
Ded пишет: Победить они, при всём их гоноре, не могут, но вот подосрать могут любому лидеру Однако уже на 4 место сползли. Совсем расслабленная эта неделя? Могут ведь и рекорд 3307 обойти, если экстраполировать тупо на неделю.
Re: Старт маркетингового развития.
Ded пишет: En101.CzechRepublic Вау! Это ж Ипполит, то есть тьфу, американский английский! Что-то его долго не было :-D Так его же убили кажется? Видать воскрес. P.S. А я все ленился зарегистрироваться на гугле. Написал до это несколько сообщений, получил несколько отлупов и забил на это дело. Сегодня наконец-то зарегился, преодолев этот лежачий полицейский для спамеров. И что я тут вижу? Правильно, спамера.
Re: Сравнительные тесты FB(IB) и других СУБД
Dmitri Kuzmenko пишет: т.е. грамотные кроссплатформенные приложения - это утопия? В общем, да. Не то чтобы совсем утопия, но во многих случаях дейтвительно придется приводить к наименьшему общему знаменателю. 6. использовать общие компоненты доступа, типа ODBC. Чего все так боятся универсальных интерфейсов? Преимущества native компонент проявляются только в использовании специфического функционала. А разницу скорости за счет накладных расходов, которую чаще всего упоминают, можно заметить пожалуй только в случаях очень интенсивного потока запросов с одного клиента. то есть, такое грамотное приложение 1. не должно использовать триггеров и процедур Скорее наоборот: процедуры дают возможность скрыть внутри них некоторые различия серверов. Разумеется, сами тексты процедур будут разные и, соответственно, стоимость разработки-сопровождения в этой части надо умножить на два (грубо). вот и получается, что при таком количестве оглядок, да еще пункте 6 из первого списка, мы никогда не получим максимально эффективное для конкретного сервера приложение. То есть, это будет некий середнячок, которого побьет любое заточенное на конкретный сервер приложение. Да и стоимость такой разработки, imho, будет много выше. Все верно, но это не превращает кроссплатформенные системы в утопию. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сравнительные тесты FB(IB) и других СУБД
Yurij пишет: ошибку без малейших пояснений что она значит. Переделали на компоненты прямого доступа - стало работать в 5 раз быстрее и ошибки пропали. Интересно, что же именно стало работать в 5 раз быстрее и за счет чего? Если не рассматривать специфические случаи, то это скорее всего признак кривого дизайна. Запросы стали в 5 раз быстрее выполняться? Фетч результатов в 5 раз быстрее? Не верю. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: пятница продолжается - гибибайт
Константин пишет: ИМХО, если бы спросили МОЁ мнение, - . И вообще, не терпелось им к 10-й системе свести... так и сводили-бы себе, типа KiTenByte, GiTenByte, ... Вот потому и не спросили твое мнение :) Приставки кило гига мега и т.д. существовали и до появления байтов и имели четкое определение, понятное всем. Потом мизерная часть населения земли возвела 2 в 10 степень и получила 1024 - число, близкое к 1000. И для своего удобства обозвали кило-... Отсюда и началось разное понимание одного и того же. Гигабайт - это 10 байт. А ты можешь не заглядывая в справочник или в калькулятор написать, сколько байт в твоем гигабайте, который 2 в 30й степени? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: пятница продолжается - гибибайт
Константин пишет: Потом мизерная часть населения земли возвела 2 в 10 степень и получила 1024 - число, близкое к 1000. И для своего удобства обозвали кило-... Ну насчёт мизерности - это ты зря ... Да? И какая же доля от 6 миллиардов имеет близкое отношение к IT? А вот доля тех, кто сталкивается с IT на потребительском уровне уже гораздо больше. И для них двоичная система противоестественна. А насчёт 1000 как Кило, Мега, ... ну не понимаю, я по крайней мере, как можно правила 10-й СИСТЕМЫ применять к 2-й А если взять 8-ю систему счисления или 16-ю И для каждой выдумывать свои приставки ? Тут можно долго спорить ... Тут не о чем спорить. PS: я кстати совсем не удивляюсь что судебный процес против ... был выигран ! Почему-то до сих пор живы Дюймы, фунты, футы, локти ... и их никто не приводит к каким-то абстрактным Кило если работаем в N-й системе счисления - то и пользуемся её нотификацией, какой бы она ни была абсурдной, и/или совпадала/повторялась. Всё воспринимаеться в контексте данной системы счисления ... В контрексте какой системы счисления должна восприниматься надпись на жестком диске 160 гигабайт? В двоичной системе нет цифры 6. Отсюда и началось разное понимание одного и того же. Гигабайт - это 10 байт. А ты можешь не заглядывая в справочник или в калькулятор написать, сколько байт в твоем гигабайте, который 2 в 30й степени? Представь себе - могу, меня так в универе, в своё время, науськали ... (правда в уме только до терабайта, и то со А полтора гига? Обратный вопрос - а ТЫ можешь без калькулятора 10 байт записать в двоичном виде (8-м, 16-м) ? Нет. А зачем? Оно же длинное получится и, соответственно, неудобное для бытового применения. В шестнадцатеричном короче, но непривычно. Полтора гига будет 15. А в шестнадцатеричной надо 3B9ACA00 умножить на полтора (кстати, как полтора пишется в шестнадцатеричной? 1.8?). Значит надо 3B9ACA00 умножить на 1.8. Виндовый калькулятор, кстати, это не понимает. Ладно, сделаю так: 3B9ACA00 + 3B9ACA00/2 = 3B9ACA00 + 1DCD6500 = 59682F00. Это и есть 1 500 000 000 в десятичной. Супер удобно? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблицы
Dmitri Kuzmenko пишет: ты меня совсем не понял. селективность как и гистограммы основываются на текущих данных. а данные во времени меняются. Вот меня и интересовало - эти данные собираются на ходу, или дискретно. На этот вопрос я уже ответил. По-умолчанию на ходу. Если на ходу, то как то это imho неоптимально. Не готов обсуждать оптимальность с цифрами в руках. Устраивает более чем. Но если вдруг это действительно станет актуально, то автоматический сбор статистики на ходу можно отключить опцией БД UPDATE_STATISTICS: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbdaen9/0775.htm И тогда собирать либо вручную либо настроить сбор штатным шедулером ASA. И есть вопрос по поводу разрядности сетки гистограммы - то есть, сколько там хранится значений, 10, 100? Зависит от размера таблицы и характера распределения значений в колонке. В общих словах есть по упоминавшейся ранее ссылке: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0392.htm Наблюдал для некоторых полей в таблицах гистограммы до 200 шагов. Помимо диапазонов в гистограммах может хранится информация и для одиночных значений, по которым много записей. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Обсуждение проблемы целостности страниц (по ODS) в момент записи/чтения в PIO_ read/write
Alexey Kovyazin пишет: В общем, лучше было бы сделать сервер устойчивым к мусору на страницах и багам - т.е. чтобы когда он видит битую запись, включал бы механизм ее уборки/автофикса, Молча? А может лучше сделать этот механизм как-то особым образом запускаемым? А то тихо уберет-заавтофиксит и никто этого не заметит. Если данные останутся целыми - прекрасно, но если есть вероятность их потери (или уже потеряны), то я предпочел бы падение с криком. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Dmitri Kuzmenko пишет: Ты лучше скажи, как там у вас с пересчетом селективности индексов - когда она делается? А зачем нужна селективность индексов если есть гистограммы распределения значений в полях? Статистика собирается и апдейтится обычно автоматически, но при необходимости есть возможность дропнуть ее: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0405.htm или пересоздать: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0374.htm А вот и банальности в общих словах про Optimizer estimates and histograms: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0392.htm Цитата оттуда: Adaptive Server Anywhere updates histograms as a by-product of query execution. As queries are executed, Adaptive Server Anywhere compares the number of rows estimated by the histograms for a given predicate with the number of rows actually found to satisfy the predicate, and then adjusts the values in the histogram to reduce the margin of error for subsequent optimizations. Этот процесс можно наблюдать, если интересно. Например дропнуть статистику, начать выполнять запросы с разными условиями и смотреть при этом как заполняется и уточняется статистика: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0640.htm --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Horsun Vlad пишет: Ты лучше скажи, как там у вас с пересчетом селективности индексов - когда она делается? А зачем нужна селективность индексов если есть гистограммы распределения значений в полях? Индексы бывают из более чем одного поля. Понял. Увы, не вникал. Не владею вопросом. Этот процесс можно наблюдать, если интересно. Например дропнуть статистику, начать выполнять запросы с разными условиями и смотреть при этом как заполняется и уточняется статистика: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0640.htm А сравнивать её с настоящей потом никто не пробовал ? Не понял вопроса. А в чем сомнения? Сейчас попробовал дропнуть статистику в одной табличке с 4 млн записей. Повыполнял в системе несколько запросов с разными условиями. Первые выполнения, естественно, заметно тормозили. Взял из гистограммы первое попавшееся значение и сравнил с фактическим распределением. Совпадает. А должно было не совпадать? Поехать она может при определенных условиях, как я понимаю. Но первый же запрос, который наткнется на несоответствие, уточнит ее. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Не понял вопроса. А в чем сомнения? Сейчас попробовал дропнуть
Пожалуй, дропанье статистики дало не очень показательный пример. Вот
имел честь наблюдать как расхождение, так и исправление. Вызвал по
другой базе следующее
call sa_get_histogram ('store_id','store_movement')
Получил для store_id=7 величину 0.0028850038
А результат такого запроса:
SELECT cast((select count(*) from store_movement where store_id=7)as
double)/ (select count(*) from store_movement)
вернул 0.0030593773
И этот же запрос подкорректировал величину - второй вызов
sa_get_histogram показал уже исправленное значение 0.0030593773
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Vlad Horsun пишет: А что ты ожидал там увидеть? Документацию. а не Это же общие фразы, Именно документации предостаточно. А под предвзятостью я имел в виду не столько приверженность к разным серверам, сколько твою позицию, IMHO несколько отличающуюся от позиции пользователя СУБД. Ты все-таки разработчик сервера. Ага. Сколько коннектов, столько и совершено разных приложений с абсолютно разными запросами. Угу. Логично. Ирония непонятна. Даже в рамках однотипных рабочих мест паттерны работы и интересующие данные могут заметно отличаться. Кладовщик склада комплектующих с несколькими тысячами наименований, лежащих на складе, и склад сырья например деревообработки, где лежит всего несколько сортов шпона, клей, смола. Продажники: кто-то работает по одному-двум VIP-клиентам, а кто-то скопом со всеми остальными и т.д. Приложение одно и то же, а вот запросы из одних и тех же форм могут заметно отличаться как по форме, так и по значениям основных параметров отбора. Так что я бы не стал так категорично утверждать подобное: Кеш планов на коннект - это ещё один маразм, косвенно показывающий, что не Всё, всё. Надоело. Тут не форум по о[б]суждению ASA :) Разумеется. Сворачиваюсь. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблицы
Horsun Vlad пишет: Это слишком просто. Выполни запрос с разными диапазонами, т.е. store_id between 1 and 100, store_id between 20 and 400, и т.п., а потом смотри на статистику. Поправлять по конкретному значению - не спортивно :) Посмотрел бегло по гистограмме с большим кол-вом шагов и относительно равномерным распределением. Что-то пересчитывает по задетым диапазонам, похоже не досконально точно, если диапазон запроса охватывает большое число шагов гистограммы. Иногда дробит или наоборот - расширяет границы имеющихся шагов, особенно если увеличение диапазона не приводит к увеличению частоты для него (например увеличение диапазона с отсутствующими записями за счет соседнего). Детально не анализировал и не считал. Могу лишь подтвердить, что оно таки работает :) --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Vlad Horsun пишет: И кто его знает, когда ASA решит его из кеша выкинуть Если разработчики признаются - расскажу. Когда факт выполнения будет сильно отличаться от плана. Но это уже поздно, т.к. плохое выполнение запроса уже произошло. Ответил Glenn Paulley (Research and Development Manager, Query Processing, iAnywhere Solutions Engineering): The server monitors the access plan used for a query in a stored procedure, and if the same plan is used 10 times in a row, that plan is cached and is used for the 11th execution. Periodically, on a logarithmic scale, the query is re-optimized and the plan is compared to the previous one. If it is still the same, the cached plan continues to be used. Queries will be reoptimized at least every 640 times (that is the end of the log scale). A plan cache is abandoned when - user disconnects - any schema modification - any reset of any option setting --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Yuris W. Auzinsh пишет: HV Спасибо, но - где тут про автоматическую корреляцию плана запроса HV с параметрами в зависимости от их значенией в рантайме ? Значит Вы будите первыми! ;-) Вторыми :) --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Horsun Vlad пишет: HV Спасибо, но - где тут про автоматическую корреляцию плана запроса HV с параметрами в зависимости от их значенией в рантайме ? Значит Вы будите первыми! ;-) Мы спим первыми, а вы нас будите всё время :) Вторыми :) Ссылка ? Да обсуждали уже. В ASA параметры влияют на план. Для меня скорее откровением было то, что в других серверах это не так. http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0404.htm Цитата: Optimization proper commences just before execution. If you are using cursors in your application, optimization commences when the cursor is opened. Unlike many other commercial database systems, Adaptive Server Anywhere *optimizes each statement just before executing it*. ... Because Adaptive Server Anywhere performs just-in-time optimization of each statement, *the optimizer has access to the values of host variables* and stored procedure variables. Hence, it makes better choices because it performs better selectivity analysis. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Horsun Vlad ïèøåò: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0404.htm Öèòàòà: Optimization proper commences just before execution. If you are using cursors in your application, optimization commences when the cursor is opened. Unlike many other commercial database systems, Adaptive Server Anywhere *optimizes each statement just before executing it*. Íó, ýòî æå ÿâíûé ìàðàçì. Ïðî ìàðàçì - ýòî ñãîðÿ÷à. IMHO ìàðàçì - ýòî èñïîëüçîâàíèå åäèíîãî ïëàíà äëÿ âñåõ âîçìîæíûõ çíà÷åíèé ïàðàìåòðîâ. È ïîíÿòèå ïëîõîé èíäåêñ ìíå òîæå êàæåòñÿ äîñòàòî÷íî ìàðàçìàòè÷íûì. Óïðîùåííûé, íî æèçíåííûé ïðèìåð - îòáîð äîêóìåíòîâ, ñêàæåì ïî ïåðèîäó, ñêëàäó è ñòàòóñó. Åñòü èíäåêñ ïî äàòå, FK ïî ñêëàäó, èíäåêñ ïî ñòàòóñó. Äàòà áîëåå-ìåíåå ðàâíîìåðíà, ñêëàäû çàìåòíî îòëè÷àþòñÿ îáúåìîì ïîòîêà äîêóìåíòîâ, à ðàñïðåäåëåíèå ïî ñòàòóñó âîîáùå ñóïåð ïåðåêîøåííîå - 99% çàêðûòû è î÷åíü íåáîëüøîå êîë-âî â îáðàáîòêå. Êàêîé èíäåêñ îïòèìàëüíåå áóäåò? Áåð¸ì ïðîöåäóðó òèïà ... òû õî÷åøü ñêàçàòü, ÷òî êàæäîå âûïîëíåíèå âíóòðåííåãî select'à áóäåò îïòèìèçòðîâàòüñÿ çàíîâî ? Äëÿ ïðîöåäóð, ôóíêöèé è òðèããåðîâ ñäåëàíî èíòåëëåêòóàëüíîå êýøèðîâàíèå ïëàíîâ: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0403.htm Âêðàöå ñìûñë: ïîñëå íåñêîëüêèõ âûïîëíåíèé îïåðàòîðà ñòðîèòñÿ reusable ïëàí. Îí íå çàâèñèò îò çíà÷åíèé ïåðåìåííûõ. Åñëè ñòîèìîñòü òàêîãî ïëàíà áëèçêà ê ëó÷øåé çàôèêñèðîâàííîé ñòîèìîñòè çàïðîñà, òî ïëàí äîáàâëÿåòñÿ â êýø è èñïîëüçóåòñÿ â äàëüíåéøåì.  ïðîòèâíîì ñëó÷àå çàòðàòû íà îïòèìèçàöèþ íà êàæäîì èñïîëíåíèè ïåðåâåøèâàþòñÿ âûãîäàìè îò îïòèìèçàöèè è ïðèíèìàåòñÿ ðåøåíèå íå êýøèðîâàòü, à îïòèìèçèðîâàòü êàæäûé ðàç. Çàïðîñû ñ ñîõðàíåííûìè â êýøå ïëàíàìè ïåðèîäè÷åñêè ïåðåîïòèìèçèðóþòñÿ äëÿ ïðîâåðêè îòíîñèòåëüíîé ýôôåêòèâíîñòè ñîõðàíåííîãî ïëàíà. Íàôèã-íàôèã òàêîé 'îïòèìèçàòîð' Íèêòî æ íå çàñòàâëÿåò :) Ïðîñòî óïîìÿíóë ê ñâåäåíèþ. P.S. Ãèñòîãðàììû â FB ïëàíèðóþòñÿ?  roadmap óïîìèíàåòñÿ ñî ñðåäíèì ïðèîðèòåòîì Optimizer improvements ... more data statistics --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Вторая попытка отправить читаемый ответ :) Horsun Vlad пишет: Ну, это же явный маразм. Про маразм - это сгоряча. IMHO маразм - это использование единого плана для всех возможных значений параметров.(И понятие плохой индекс мне тоже кажется достаточно маразматичным). Упрощенный, но жизненный пример - отбор документов, скажем по периоду, складу и статусу. Есть индекс по дате, FK по складу, индекс по статусу. Дата более-менее равномерна, склады заметно отличаются объемом потока документов, а распределение по статусу вообще супер перекошенное - 99% закрыты и очень небольшое кол-во в обработке. Какой индекс оптимальнее будет? Берём процедуру типа ... ты хочешь сказать, что каждое выполнение внутреннего select'а будет оптимизтроваться заново ? Для процедур, функций и триггеров сделано интеллектуальное кэширование планов: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0403.htm Вкраце смысл: после нескольких выполнений оператора строится reusable план. Он не зависит от значений переменных. Если стоимость такого плана близка к лучшей зафиксированной стоимости запроса, то план добавляется в кэш и используется в дальнейшем. В противном случае затраты на оптимизацию на каждом исполнении перевешиваются выгодами от оптимизации и принимается решение не кэшировать, а оптимизировать каждый раз. Запросы с сохраненными в кэше планами периодически переоптимизируются для проверки относительной эффективности сохраненного плана. Нафиг-нафиг такой 'оптимизатор' Никто ж не заставляет :) Просто упомянул к сведению. P.S. Гистограммы в FB планируются? В roadmap упоминается со средним приоритетом Optimizer improvements ... more data statistics --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Horsun Vlad пишет: Если стоимость такого плана близка к лучшей зафиксированной стоимости запроса, то план добавляется в кэш и используется в дальнейшем. Это работает только если пар-ры не плавают. Рассчитывать на это - глупо (маразм :) Нет, все-таки возражу ;) Как раз таки наоборот: если они сильно плавают, то скорее всего выгоднее будет каждый раз оптимизировать, чем тупо лепить один и тот же план со всеми возможными значениями параметров. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Vlad Horsun пишет: Дык - план-то уже в кеше. И не факт, что самый хороший :-D Разумеется. По этому поводу я могу опять привести ссылку и цитату для детсада :) http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0390.htm A good plan, not necessarily the best plan The goal of the optimizer is to find a good access plan. Ideally, the optimizer would identify the most efficient access plan possible, but this goal is often impractical. Given a complicated query, a great number of possibilities may exist. И кто его знает, когда ASA решит его из кеша выкинуть Если разработчики признаются - расскажу. Уж при дисконнекте клиента точно выкинет --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Vlad Horsun пишет: Да, да. Когда такое читаю, думаю - иногда лучше молчать, если сказать нечего. Хороший пример документации ASA :) А что ты ожидал там увидеть? Это же общие фразы, basic concepts так сказать. Большего и не нужно для решения большинства задач и достаточно, что бы в общих чертах получить представление, не будучи специалистом по разработке серверов БД :) Ты ж не ожидаешь, что в инструкции по эксплуатации современного авто будут математические выкладки из сопромата и термодинамики? Взгляд у тебя немножко предвзятый. Уж при дисконнекте клиента точно выкинет Конечно - кеш-то только в рамках коннекта живёт :-D Могу сделать вывод, глядя на работу реальных систем, что тоже вполне логично. Разные коннекты - разные юзеры и, возможно, разные потребности в выборках данных. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Сверхбольшие таблиы
Vlad Horsun пишет: А что есть идеал по твоему? Не вообще, а по данному вопросу. Все равно ведь компромисс искать надо между затратами на оптимизацию и эффектом от этой самой оптимизации Идеал - идеальный план для любых значений пар-ров :-D Который недостижим, как и большинство прочих идеалов. ASA ведёт себя не предсказуемо - план запросов в процедурах может быть далёк от оптимального. Да, те же запросы, выполненные отдельно, имеют шансы быть лучше оптимизированными (за счёт постоянного перевычисления плана), но в моей практике 95% запросов живёт таки в процедурах. В моей практике скорее наоборот. P.S. Кстати, в случае некоторых примитивных селективных процедур вообще не мыслю, как можно без оптимизации при исполнении. Если процедура - просто селект с джойнами и условиями, то при выборке из нее план строится не только с учетом значений параметров, но и с учетов условий, накладываемых на выборку извне. Весьма удобно в разработке. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re:
Dmitry Yemanov пишет: SELECT * FROM EMPLOYEE e, DEPARTMENT d WHERE e.workdept = d.deptno AND d.deptno = ? selectivity 0.25 Поясните убогому, что означает этот запрос? Что ожидается, что подсунутый параметр выберет 4 записи. А ты уверен? Не ориентируюсь в DB2, но в ASA похожая запись будет означать, что условию AND d.deptno = ? удовлетворяют 0,25% записей из DEPARTMENT. http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0040.htm --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re:
Вот из доки по DB2: The SELECTIVITY clause is used to indicate to DB2 what the expected selectivity percentage is for the predicate. SELECTIVITY can be specified only when the predicate is a user-defined predicate. Так что там 0,25 пожоже означает не 4 записи по условию, а четверть записей в таблице. Аналогично в ASA, только там в процентах. --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Off. Ищу программку.
Использую FastStone Image Viewer http://www.faststone.org/FSViewerDetail.htm (по совету г-на Голубицкого из КТ: http://offline.computerra.ru/print/offline/2005/606/229240/ ) Пакетно повернуть-уменьшить-пожать-вставить дату/время - самое то что надо. И как viewer весьма радует. No Adware No Spyware Free for Home Users --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Visit our club
пишет: (о пользе кирилицы в поле From :) Инетерсно, а почему в epsylon спама не было? А кто про него знал? Здесь же новостной сервер, количество юзеров которого на порядки превосходит эпсилоновские --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Statement триггеры
Alexandr Kochmin пишет: Вот например, самомодифицирующитеся таблицы при селекте. Реализация квантовых принципов в субд, когда наблидатель самим фактом наблюдения переводит кошку в черном ящике из размазанного состояния в мертвое либо живое? Ничего особенного, просто поле в табличке менять при селекте. Лучше поменять что-то не в табличке, а в консерватории. Или... хм. сразу не вспомню. Но если и вспомнишь объективные потребности, то было бы интересно, чем не устраивает использование, например, хранимых процедур, если уж так нужно отрабатывать чтение данных.
Re: помогите со структурой базы.
Alexandr Kochmin пишет: AG В чем именно сложность то? так вот как раз в стрктуре. с учетом этих пунктов. Я расчитываю что тут досточно 2-3 таблиц, а между строк твоего ответа я прочитал что тут аж ЦЕЛЫЙ СКЛАД надо. Так это новая часть имеющейся системы или просто новая маленькая системка? Справочник складов, справочник всей номенклатуры (включая инструменты и услуги, с соотв. признаками). Таблица складских движений. Таблицы для документов для операций прихода, расхода, перемещения (объединить по вкусу), для операций преобразования (сборка-разборка, выбраковка и т.п.) Вот вроде все. Может что-то упустил.
Re: помогите со структурой базы.
Alexandr Kochmin пишет: Это ж не танк надо, а так, маленький самокатик. Главное чтоб ездил. Аппетит приходит во время еды. На самокатик потом захочется моторчик прикрутить в 100 лошадей, подушку безопасности, кондиционер, ABS и т.п. Можно, конечно, извратиться в плане усечения. Например убрать справочник номенклатуры - вместо него использовать просто приходы (кстати, удобный вариант для учета уникальных изделий) и т.п. Но 1-2 таблицы - это вряд ли. А чтоб юзеру было просто и понятно, так это вопрос не кол-ва таблиц, а идеологии интерфейса.
Re: Индекс по сильно не уникальному полю
Dmitry Yemanov пишет: Имеет. Но в условиях состояние = оплачен придется гасить индекс через +0. А гистограммы в отдаленных планах есть? В roadmap нашел только такое упоминание: Optimizer improvements. , more data statistics
Re: Индекс по сильно не уникальному полю
Dmitry Yemanov пишет: Есть. Но если состояние передается параметром, то толку в них никакого. Т.е. по prepare план строится сразу еще до получения значений параметров?
Re: Индекс по сильно не уникальному полю
Horsun Vlad пишет: А что в ASA делает препаре ? Выделяет буфер в N MB на всякий случай ? :))) Не сильно заморачиваюсь этим вопросом, ибо делаю отдельный prepare крайне редко, можно сказать никогда в штатной работе. В документации описано не очень внятно. Есть такой абзац: Normally, the optimizer selects an access plan for a query every time the query is executed. Optimizing at execution time allows the optimizer to choose a plan based on current system state, as well as the values of current selectivity estimates and estimates based on the values of host variables. А для запросов в процедурах, функциях и триггерах может быть использовано кэширование планов, если план, построенный без использования host variables близок по стоимости к лучшему плану запроса, полученному ранее. http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbugen9/0403.htm
Re: Индекс по сильно не уникальному полю
Horsun Vlad пишет: Не сильно заморачиваюсь этим вопросом, ибо делаю отдельный prepare крайне редко, можно сказать никогда в штатной работе. Если ты его не делаешь явно - это ещё не значит, что он не делается вообще Разумеется, оно делается сервером. Т.е. переоптимизирует при каждом выполнении ? Некузяво это, имхо Ну, смотря что с чем сравнивать. За то отсутствует понятие плохого индекса, можно смело делать индексы на поля типа статусов, как описано в начальном посте. Мною визульно накладные расходы на оптимизацию на большинстве задач не обнаружены. А если с явным препаре ? Вот что есть в доке про preparing: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbpgen9/0020.htm Пишут, что generate an access plan if the statement involves joins or subqueries. Что за этим скрывается на самом деле - не знаю. Но похоже на запросах с параметрами без явного prepare план строится в зависимости от значений параметров. Следует ещё понимать, что в ASA (да и в MSSQL) процедура - это набор _отдельных_ statement'ов, каждый из которых имеет свой план выполнения, а у нас - процедура есть один statement с единым планом выполнения Можно подробнее эту мысль? Что значит план для процедуры, в которой внутри куча разных, возможно несвязанных между собой запросов?
Re: Индекс по сильно не уникальному полю
Horsun Vlad пишет: Да где же оно отсутствует ? Оберни запрос в процедуру, выполни её 10 раз с хорошим значением параметра а потом с плохим, что будет ? Проверю такое на досуге. В доке по первой ссылке по этому поводу сказано только в общих словах: The optimizer periodically re-optimizes queries to verify that the cached plan is still relatively efficient. Что значит periodically - без понятия. Это не open source :( Есть процедура, у неё единое parse tree и единая стр-ра, подаваемая на вход executor'у - что тут непонятного ? :) Грубо говоря - объединение планов отдельных statement'ов (в вашем понимании) Понял. Кстати, похожую тему обсуждали уже, и кажется с твоим участием в fido7.su.dbms, но я так и не понял, может ли в FB план процедуры отличаться в зависимости от значений, передаваемых в процедуру. Я имею в виду именно параметры процедуры, а не параметры запроса.
Re: Программно определить реальную версию Firebird-а ???
Dmitry Yemanov пишет: Что тебе еще надобно, старче? :-) А пожеланий сделать это доступным из SQL еще не поступало? Я не желаю, просто любопытствую :) IMHO это удобнее, чем в API лезть.
Re: Индекс по сильно не уникальному полю
Horsun Vlad пишет: Угу, за то и любима птица, что можно получить ответы на вопросы ;) да еще и на русском языке :) Кстати, похожую тему обсуждали уже, и кажется с твоим участием в fido7.su.dbms, но я так и не понял, может ли в FB план процедуры отличаться в зависимости от значений, передаваемых в процедуру. Я имею в виду именно параметры процедуры, а не параметры запроса. Не помню такого обсуждения, Гугл помнит. Где-то тут: http://groups.google.ru/group/fido7.su.dbms/tree/browse_frm/thread/afe5507054a2ae56/0499696186d3f380?q=postgresql+vs+group%3Afido7.su.dbmshl=rurnum=50 Но топик был длинный, нафлеймили много
Re: Кажись, сбывается мечта многих (идиотов? :-)
Dmitry Yemanov пишет: С номенклатурой организационно немного проще IMHO, ибо обычно точек возникновения новой номенклатуры все-таки поменьше, чем для контрагентов. На последних моих работах номенклатуры было на порядок больше контрагентов. Я про другое. Номенклатуры больше. Но точек возникновения новой номенклатуры может быть при этом меньше. Утрированный пример: новые контрагенты возникают в фин.отделе, ОМТС, отделе продаж, транспортном и т.п. А новая номенклатура возникает только в конструкторско - технологическом отделе. Хотя, конечно, зависит от специфики.
Re: Кажись, сбывается мечта многих (идиотов? :-)
Boltik Evgeny пишет: Хорошо что кто то помнит. А чтука очень важная т.к. юзеры столько дубликатов делают ужас. http://sql.ru/forum/actualthread.aspx?tid=276943#2501869
Re: Кажись, сбывается мечта многих (идиотов? :-)
Ded пишет: Кстати, о птичках, сиречь ООО. Я в своё время ещё при проектировании с карандашем и резинкой выделил формы собственности в справочник Логично, но это лишь частное решение для случая, когда есть такие выносящиеся в справочники атрибуты. Оно снимает только часть проблемы. Проблемы вариаций в написании значащего наименования при этом не исчезают. А в приведенном по ссылке примере вообще показан справочник контрагентов в более широком смысле этого слова, нежели в понимании бухгалтеров. У контрагента может быть не один десяток юр. лиц, никак не связанных между собой, и имеющих различные формы собственности. А за ведение справочника собственной номенклатуры кем ни попадя, надо, конечно, канделябром :) С номенклатурой организационно немного проще IMHO, ибо обычно точек возникновения новой номенклатуры все-таки поменьше, чем для контрагентов. Хотя, конечно, зависит от специфики.
Re: Кажись, сбывается мечта многих (идиотов? :-)
Plotnikov Y. пишет:
думал минуты две, не врубился - че он делает?
Похоже, это инсерт, который в случае если такая строка уже есть апдейтит
ее, либо удаляет ее и вставляет предложенное по новой. Такое есть в MySQL:
http://dev.mysql.com/doc/refman/5.0/en/replace.html
и в SQL Anywhere чуть более продвинутый вариант:
INSERT [ INTO ] [ owner.]table-name [ ( column-name, ... ) ]
[ ON EXISTING { ERROR | SKIP | UPDATE } ]
...
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0435.htm
Re: Тест по SQL
Konstantin R. Beliaev пишет: Интересно, а другие сервера смогут распознать такую конструкцию и задействовать индекс? Мне почему-то кажется, что это универсальный трюк. Само понятие плохой индекс в контексте выборки данных достаточно неуниверсально, скорее специфично для IB/FB и rule based оптимизаторов. Не скажу за все другие, но в Sybase ASA +0 не мешает оптимайзеру выбрать индекс. Этот +0 до него просто не доходит - исчезает еще на этапе предварительного переписывания запроса.
Re: Написание агрегируюих функций в FB
Oleg LOA пишет: Велкам ту оракле ;-) Неужели LIST в FB не переедет?
Re: Написание агрегируюих функций в FB
Oleg LOA пишет: Конечно можно выкрутиться и хранимой процедурой, но это к проктологии ближе Велкам ту оракле ;-) Шутку понял, только когда глянул в FAQ по Oracle на sql.ru: http://sql.ru/forum/actualthread.aspx?tid=212946 14-й вопрос. Я думал там с этим получше
Re: Написание агрегируюих функций в FB
dada sasa пишет: агрегация строк? а что это? не слышал раньше, не поясните, плиз? Аналог SUM, но для строк - агрегатное склеивание. Функция LIST, типа вот такой: http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/0220.htm
Re: Написание агрегируюих функций в FB
Yurij пишет: Ох, не помешало бы это и в Firebird :) Оно есть в Yaffil, но чуть попроще. Можно предположить, что и в FB оно будет перенесено (если еще не перенесли). Но чего я не могу понять, так это как при выполнении такого запроса рассчитывается размер поля с результатом LIST - там же может быть очень много строк. В SQL Anywhere это long varchar.
Re: не просто к пятнице
aLKoGolik пишет: Меня вечно убивает слова от ... Да скажи прямо сколько-то испыталка сколько-то после, если подходишь. Иногда от... действительно означает от У меня свежий личный пример - искали эникейщика, а заполучили человека, который вполне может потянуть и руководство IT-отделом. Соответственно зп после испытательного в разы отличается от предполагавшегося уровня. Квалифицированного спеца, знающего себе цену, не должны убивать слова от Называешь свою цену и торгуешься. Не согласны - до свидания, работодателей много.
Re: Вакансия в Киеве
Oleg LOA пишет: Гм, Вы бы хоть вопросы поприличней сформулировали. Неужели вакансия заинтересовала? При чем тут размер БД и число записей в таблице и количество объектов? Например чтоб прикинуть начальную з.п. Типа $500 + натуральный логарифм от максимального кол-ва записей на прошлой работе.
Re: OFF Доступ к Ораклу
StepanischtevS пишет: Подскажите как лучше доступаться к Oracle из Delphi 2006. Интересуют больше отзывы по результатам реализованных проектов насколько те или иные компоненты глючные и в полной мере поддерживают функциональность Oracle . А что значит полная поддержка функциональности в контексте разработки системы, поддерживающей разные сервера? Стоит посмотреть в сторону универсальных способов доступа. Например через ADO.
Re: ibase.ru
Dmitri Kuzmenko пишет: Ждем. может у хостера что, а может, в интернете авария какая. В 100mb сказали, что проблема у вышестоящего провайдера. Чинят. Сроки неизвестны.
Re: Если Ковязин и Востриков еще борются с пиратами
Легально в электронном виде где можно купить?
Re: OFF про qwerty
Alex Cherednichenko пишет: Вы пишешь ... Ага, щаззз... А ты случайно не Мимопроходящий?
Re: OFF про qwerty
Alex Cherednichenko пишет: Ага, щаззз... http://en.wikipedia.org/wiki/QWERTY и что? http://www.urbandictionary.com/define.php?term=qwerty http://www.google.ru/search?hl=ruq=qwerty+keyboard+for+slow+downbtnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BAlr=
Re: OFF про qwerty
Alex Cherednichenko пишет: URBAN и надписи на заборах как и википедия вызывают равную степень доверия к публикуемой информации. Если тебя очень интересует история вопроса, загляни в Британику. Британика более уважаемый источник, но поиск по qwerty ничего не дал. Лень мне спорить с тобой по этому вопросу. Поверю на слово, будем считать это популярной байкой. P.S. Кстати, а о чем спорим то? Вот цитата из приведенной тобой ссылки с вики: Frequently used pairs of letters were separated in an attempt to stop the typebars from intertwining and becoming stuck, thus forcing the typist to manually unstick the typebars and also frequently blotting the document. Сильно отличается от сказанного мной? Суть то та же: первичная задача QWERTY не ускорение набора, а предотвращение typebars from intertwining and becoming stuck и т.п.
Re: OFF про qwerty
Alex Cherednichenko пишет: AG QWERTY не ускорение набора, а предотвращение typebars from intertwining AG and becoming stuck и т.п. Но отнюдь не ...УМЫШЛЕННО разрабатывали так, чтобы УМЕНЬШИТЬ скорость ввода... Ну ладно, открыть глаза на заблуждения по поводу стандарта ANSI SQL, но такую красивую байку зачем портить то? Тем более не очень далекую от истины. Я латиницей набираю, пожалуй, побольше чем кирилицей, но все равно по русски получается значительно быстрее и практически не глядя на клаву, а вот с QWERTY на порядок хуже. (Слепым десятипальцевым не владею)
Re: OFF: сдох винт
Vlad Nepomnjashy пишет: Посоветуйте что-нибудь умное А неумное задним умом, которым мы все сильны, можно? :) Когда-то в досовские времена, когда NDD не мог справиться с восстановлением, он выдавал красную табличку с нравоучительной надписью Backup often. Если не помогут предложенные ранее инструменты, можно ради интереса попробовать загрузиться с какого-нибудь свежего Live CD с Linux, например ASPLinux 10 GreenHorn. Насколько я помню, он монтирует NTFS разделы ro. Вдруг поможет. или пошлите куда-нибудь, где могут помочь. http://www.datarecovery.ru/
Re: Firebird hosting
Oleg Deribas пишет: Есть еще варианты? Причем хотелось бы заранее быть уверенным что есть перспектива на fb 2.0 ... http://100mb.ru/services/ Смотри выделенный виртуальный хостинг или аренду физических серверов. Полагаю в обоих вариантах можешь запросто установить себе любой FB по вкусу.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: Угу, т.к. общий размер получается 20 Мб* число подключений. Это как у нас в классике. Удивило и разочаровало, однако. Я думал, там архитектура как в супере. http://sql.ru/forum/actualthread.aspx?tid=267757 shared_buffers я куртил - разницы в быстродействии не заметил М... да, однако. Гадание на кофейной гуще по поводу общего кэша в постгресе начинает там походить на пятничный юмор :)
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: Угу, т.к. общий размер получается 20 Мб* число подключений. Это как у нас в классике. Удивило и разочаровало, однако. Я думал, там архитектура как в супере. http://sql.ru/forum/actualthread.aspx?tid=267757
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: И какой на него (тест) дал ссылку на sql.ru? Точно не я. Но то, что оно там всплывет и начнется подобный флейм - почему-то сразу предполагал. Сглазил, наверное :) Чуствую пошлю всех в зад - как протестировал, так и протестировал. А что мешает? Каждый может повторить эти тесты у себя. Если захочет. чего ещё хочет общественность мне не понятно? Очень даже понятно. Хочет (якобы)объективного (псевдо-)научного обоснования своих религиозных убеждений.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
А что означает замечание про PG: 80% ОЗУ не получил тока PG. Т.к. он на Win32 крутился по классической архитектуре - у него 20МБ было на кэш.? Он в принципе не мог взять больше 20мб или умышленно ограничил?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: По поводу косяка с массовым обновлением lineitem на ASA9 - виноваты индексмы. Т.е. это явные грабле в ASA. Нашли способ как сократить это до 67 минут только настройками параметров. Виновата частая запись грязных страниц по причине слишком короткого интервала допустимого восстановления базы после сбоя. Не сказал бы что грабли, слишком специфичная задача. Тотже Ya отработал запрос за пару минут, А вот это интересно, за счет чего такая резвость? Forced writes? Дилетантский вопрос: а не связано ли как-то замедление подобной операции у других серверов по сравнеию с FB с тем, что есть затраты на обеспечение той самой пресловутой Statement/transaction consistency? MS копался раздувая лог 1 час, ORA выполнил быстрее Быстрее чем MS или быстрее Ya? На этом тестирование заканчиваю. Положительный эффект есть - пару косяков в FB2 подправили. А какими еще тестами пользуетесь в работе кроме TPC-R?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Так и не скомпилял я этот dbgen. Взял готовый для FB2.0 по адресу http://ibdeveloper.com/tests/tpc-r/how-to-run-tpc-r-based-test/ Сгенерил файлы с данными. Использовал ASA 9.0.2.3207 на Win2003, процессор Celeron 2.66 ггц, памяти 512 мб, винт обычный IDE. Создал базу с размером страницы 8 кб. Остальное - по-умолчанию. Запустил ее полностью по-умолчанию - командой dbeng9 tpcr.db Сделал ту таблицу lineitem Залил данные из файла стандартной командой LOAD TABLE - заливка 490 секунд, 6001215 записей Создал PK - 330 сек. Тот самый update lineitem set l_comment = trim(l_comment) - 251 секунда. За все это время максимальный размер кэша - 240 мб (по-умолчанию ASA динамически меняет размер кэша в зависимости от потребностей и наличия свободной памяти в системе) Использовавшийся комп был заментно нагружен и другими задачами, так что эксперимент далеко не слишком чистый. Если еще не потерял интерес, могу выдать: 1) последний EBF (9.0.2.3249, 75мб) 2) скрипт создания базы 3) скрипты загрузки таблиц из файлов *.tbl, которые сделал dbgen 4) командную строку для запуска бд можно и по-умолчанию использовать Правильно ли я понял, что в TPC-R просто меряется время однократного выполнения запосов 1.sql-22.sql?
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Dmitri Kuzmenko пишет: для запроса update lineitem set field = trim(field); imho оптимизатор не имеет абсолютно никакого значения. Да, неактуален. Не знаю точный номер версии у Олега, но существенные поломки в 9.0.2 в начальных выпусках были - тогда достаточно много изменений вносилось. Почему они именно его выложили на сайт, не потрудившись хотя бы упомянуть про апгрейды - без понятия.
Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Oleg LOA пишет: Тот самый update lineitem set l_comment = trim(l_comment) - 251 секунда. Я нашел косяк. У меня обновлялись в одном update три поля из которых два были индексируемыми. Чёт там shipmomode и ещё какое-то varchar. Так вот при наличии индекса ASA уходит в глубокий IO при обновлении 6 МБ записей на lineitem. Создай все 4-е индекса на lineitem и выполни update по индексируемым полям. Индексы нашел: create index lineitem_shipdate on lineitem(l_shipdate); create index lineitem_partkey_suppkey on lineitem(l_partkey, l_suppkey); create index part_brand_container_size on part(p_brand, p_container, p_size); create index lineitem_quantity_sm_si on lineitem(l_quantity, l_shipmode, l_shipinstruct); create index lineitem_shipmode_rd on lineitem(l_shipmode, l_receiptdate); Оно? Текст update дашь или самому придумать?
