SSYПредлагаю "переименовать" ASA в A$A. Так все постоянно будут помнить о том, чем он хуже FB.
Неумно. Да будет Вам известно, уважаемый, стоимость проекта определяется не только стоимостью сервера. И если уж, отбросив религиозный фанатизм, взять и посчитать эти самые $ для разных проектов, то результат Вас может сильно удивить.
Я считал, и не один раз.

Предлагаю закрыть тему. Welcome в Сравнение СУБД с подобными вещами.

kdvПоскольку идти в конференцию по ASA и начинать там такие же танцы нет никакого желания

желания или возможности?
kdv
Прямой зависимости между количеством фишек и популярностью сервера, кстати, нет.

так же как и между популярностью и качеством.
kdv
Поэтому конкретные посты для не-разработчиков FB выглядят именно так, что мол, в IB/FB все суксь, а в ASA - рулез.

Мы всего лишь решаем свои бизнес-задачи (я не про рекламу :). Воспринимать эти посты чуть ли не как личное оскорбление - это уже ты перегибаешь.
kdv
Что, в общем, по даже приведенным мелким примерам, вовсе не соответствует действительности.

Примеры были действительно мелкими. Крупные пока не трогали
fedd
Думаю, ASCRUS очень заинтересован в нашем сервере, и аргументированные ответы людей, знающих сервер изнутри, может быть, приведут к тому, что он... ну, например, перейдет на FB! :)

Да нет пока таких ответов :(
dimitrASCRUS, конечно, не упускает момента похвалить ASA при случае ;-)

я его понимаю и поддерживаю. Если работаешь с ASA и при этом (важное дополнение!) достаточно знаком с другими серверами, то возникает бескорыстное желание поделиться с другими своим открытием. Да, действительно ASA обладает уникальным сочетанием качеств, приводящих в восторг после знакомства с ним. Но это лирика. А не-лирика в том, что эти качества делают его очень оптимальным выбором для большого круга задач. А наблюдение за тем, как другие мучаются, иногда наводит на мысль, что можно помочь упростить жизнь и избавить от изобретательства многих велосипедов. Опять лирика ;) Но кто работает с АSА - меня поймет.
dimitr
Но IMHO услышать здесь точку зрения профессионала приятнее, чем наблюдать вопли ламеров "FB форева патамучта нам нифуя другого не упало и вааще он халявный" в других конференциях.

подпишусь под этими словами
dimitr
К слову, ASA нам вполне конкурент, ибо весит и жрет мало, встраивается куда угодно и не требует администрирования.

Да, они во многом похожи по идеологии. В том числе и поэтому я продолжаю поглядывать в сторону FB, хотя пока не счел возможным его использование для своих задач. Но все течет, все меняется...
dimitr
Когда один товарищ в их форуме заявил мне, что писать страницы в базу так, чтобы ее состояние было валидным на любой момент времени, в принципе невозможно, я с трудом, но сдержался ;-)
Ну, его же аргументированно опровергли ;) Со ссылками на документацию и т.п.

dimitr
Обычный дефолт работает на INSERT. Именно этого я от него ожидаю. Если я вижу вещь типа DEFAULT TIMESTAMP, у меня начинает клинить крышу. Чем этот TIMESTAMP отличается от CURRENT_TIMESTAMP?

Никто не упомянул еще одну особенность TIMESTAMP по сравнению с CURRENT_TIMESTAMP. А она IMHO значительно более полезная, чем автоматическое изменение при апдейте. Дело в том, что CURRENT TIMESTAMP может выдать идентичные значения, например при быстрой вставке большого кол-во записей. Из-за этого невозможно использовать такое поле в первичном ключе, приходится делать синтетический ключ типа автоинкремента. Если же использовать DEFAULT TIMESTAMP, то получаемое при вставке значение будет гарантированно уникальным. Оно как мимимум увеличится на микросекунду (эта величина настраивается для каждой БД). Причем уникальность сквозная, т.е. даже при вставках в разные таблицы. Весьма полезно для логов и тому подобных вещей.
Аналогично @@identity, последнее вставленное значение DEFAULT TIMESTAMP можно получить через переменную @@dbts.

dimitr Александр ГoлдунПо мне так гораздо интереснее иметь нормальный оптимизатор, инкрементальный бэкап (будет в FB2), transaction log (сейчас скажут что нафиг не нужно либо очень сложно) и еще возможность распараллеливания между несколькими процессорами при общем кэше. Триггеры в таком случае не влом действительно вручную прописать.

Прааавильно говоришь... ;-)
Кстати, не поленился скачать release notes. Не нашел упоминания распараллеливания на "супере". Плохо искал? Какие прогнозы? Как я слышал, IB 7 в этом плане продвинулся, а он для FB более непосредственный конкурент, чем ASA

А вот derived tables порадовали, спасибо (заранее :).

Мимопроходящий
> Да уж, "продвинулся"...
> Обернули нереентерабильные куски критическими секциями.
> Я про 7.1, тестировал его.


Т.е. фактические ничего не изменилось в этом плане? Просто на
http://ibase.ru/ib7.htm первым новшеством упомянута именно поддержка SMP
в IB 7.0. И как они умудряются продавать это за деньги при наличии очень
близкого конкурента - FB? Впрочем, это риторический вопрос.
Posted via ActualForum NNTP Server 1.1