Dmitri Kuzmenko wrote:
Время идет, рекомендации меняются. :-)
- система - на отдельном винте
- temp, база - можно на одном RAID 5 или 10
- бэкапы - на отдельном винте
В целях экономии можно бэкап наверное делать на системный винт, а оттуда
уже сливать по сети в надёжное место.
Dmitri Kuzmenko wrote:
Можно ли FW отключать или лучше оставить?
отключать можно, если это ФБ 2.1 и выше (см. firebird.conf)
Костыль однако. Но тем не менее...
или если
стоит raid с батарейкой. Но на raid с батарейкой может оказаться все
равно, Fw=on или off. зависит от крутизны raid.
12.07.2011 20:22, Dmitri Kuzmenko пишет:
Кстати, есть какая польза от 64-битного супера?
Вроде максимальный размер кэша как то лимитирован.
пользы нет, только если ты не упрешься вдруг в нехватку
памяти на 32-битном супере (2гига).
Таких значений, если я правильно помню, достигают люди только
Привет!
Если система ушла в своп - то где бы он не располагался - настаёт она
самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много.
Своп вроде бы всегда используется виндой для своих нужд.
Это у вас на венде. У Пингвинов немного не так:
serj@auth:~$ free
total used
Привет!
Рекомендации от экстремалов:
1) Система на SSD, своп нафиг.
Серега, своп нафиг уже давно не смешно. Не нужно его выключать,
от этого один геморрой, и лучше не будет.
Собственно, ОС на SSD это не экстрим, это просто выкидывание
денег на ветер. Для ноутбуков - да, побыстрее
13.07.2011 2:28, Dmitri Kuzmenko пишет:
можно я риторический вопрос задам, в пространство?
Поскольку ситуация с выбором железа у людей, работающих с ФБ,
просто ну никуда, не могу понять. Неужели эти люди
никогда не интересовались скоростью работы диска?
Не запускали HDTune? Не читали
тест.
Что то не фурычит создание сообщений в группе.
Тест
11 июля 2011 г. 20:17 пользователь Dmitri Kuzmenko k...@ibase.ru написал:
Hello!
Voroshin Dmitry wrote:
Что то не фурычит создание сообщений в группе.
очень даже фурычит.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
--
С Уважением
Соколюк Михаил
Dmitry Lendel ...
Привет
Я совсем запутался. Давно с этим не работал
Нужно посчитать разницу в часах и минутах
select
cast('0:00' as Time)+cast(a.Field1 as time)-+cast(a.Field2 as time)
from xf_invoice a
где Field2 timestamp
Это работает SELECT cast('0:00' AS time)+(cast('18:00' AS
Михаил Викторович wrote ...
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим делали составные
Михаил Викторович wrote:
Я написал свое мнение о том, что человек прав, придя к идее архива.
Это плохая идея.
Если уж делать ахрив, то создавая копию базы на на какой то момент времени.
В одном из проектов мы использовали архивные таблицы в той же базе. Конечно
время бакапа растет, но пока
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
На самом деле есть опредлённые проблемы у оптимизатора когда он выбирает
сливание битовых карт индексов на сверхбольшых
Михаил Викторович wrote:
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
Тогда хотелось бы услышать о выявленных узких местах в вашей ситуации.
На самом деле есть
Михаил Викторович wrote:
Кто же их упомнит. Несколько десятков определенных вручную планов.
Ручные ещё не значит хорошие.
Вставка как вставка обычная где то в три-четыре таблицы, что про нее еще
можно сказать я не знаю.
Индексов штук 8-10 в каждой таблице. При активной работе 400-650
Михаил Викторович ...
Тест интересный, но я в нем не нашел теста на вставку большие таблицы когда
уже седаны индексы, падение будет существенным,
Прям предсказатель :-D
по хорошему тоже надо бы
протестировать, будет время займусь. Мой опыт говорит о том что убирая не
нужные индексы можно
Vlad Khorsun wrote:
Да. Но это не связано с размером таблицы. Можно и на маленькой
таблице получить
большие тормоза при вставке - просто создав десятки индексов с длинными
ключами.
Вопрос то в рависимости от размера таблицы. Ведь она в любом случае
должна быть логарифмической.
PS
Так тут дело не во вставке а в общем торможении сервера (ЦПУ, винт,
память) при большой нагрузке.
Это верно.
Если это суперсервер, то естественно большое количество кривых селектов
O да Вы оказывается экстрасенс.
Прям предсказатель :-D
А то :)
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим делали
06.07.2011 18:59, Михаил Викторович пишет:
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим
Подскажите в IB была такая фигня, если в индексе низкая селективность,
то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку
в
конце, для борьбы с этим делали составные ключи добавляя в них
06.07.2011 19:43, Михаил Викторович пишет:
Можно задать вопрос по другому. Опишу ситуацию есть таблица из 1 записей
в ней есть индекс по полю у которого всего два значения(приход/расход). В IB
было замечания что одинаковые значения ключа сортируются в порядке вставки в
базу для этого IB
A K wrote:
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора.
Это ничего почти не даст. Если запросы используют только данные за
последнее время, то размер таблиц фактически не влияет за
Может вполне хватит следующих действий и при существующей структуре:
* Более производительное оборудование специально выделенное под работу
СУБД - быстрый дисковый массив, много оперативной памяти, 64битный
Firebird;
если бы мы писали на оракле или на 1С, тогда да, стандартный подход
придти к
а так, имеем таких клиентов, которые элементарно жмутся на технике и
тяжко им что-то втолковать.
Значит остальное попробовать. Был случай когда добавление двух индексов
уменьшило время выполнения операции с 30 минут до 20 секунд. Наличие
долгих снэпшот транзакций может сильно нагружать
В итоге все равно будет перегрузка по производительности. Решение с архивом
верное. Теперь когда проектирую новые системы сразу предусматриваю
архивирование. Хотя есть еще вариант, например копим данные за 10 лет потом
начинаем стирать, тем самым получаем более менее постоянный объем базы, без
On 05.07.2011 22:00, Михаил Викторович wrote:
В итоге все равно будет перегрузка по производительности. Решение с
архивом
верное. Теперь когда проектирую новые системы сразу предусматриваю
архивирование.
Тем не менее для более дельных рекомендаций по данному случаю мало
информации:
*
Тем не менее для более дельных рекомендаций ...
А зачем мне Ваши рекомендации? Разве их я спрашивал?
Я написал свое мнение о том, что человек прав, придя к идее архива. На счет
реализации на триггерах и использования передачи в другую базу возможно вам
видней, такой вариант пока не использовал и
On 01.07.2011 23:55, A K wrote:
Транзакций существенно меньше чем CRUD операций как правило.
я понимаю, что в общем случае их будет меньше. Но, например, накопил я
в логе десять изменений в разных таблицах. Идет комит транзакции.
Мне все равно придется выполнить десять EXECUTE STATEMENT к
А вот с синхронной репликацией на уровне триггеров есть реальный шанс
получить большие проблемы (по моему скромному мнению это путь в никуда).
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние
A K ...
Реальная ситуация. Большая база на большом предприятии. Работает медленно.
Что именно медленно ? Запросы или обслуживание ?
Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора.
И с чего бы оно стало быстрее ? Кривые запросы, читающие кучу не
нужной
On 04.07.2011 19:48, A K wrote:
Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора. Изменения в оперативной БД, должны попадать
на архивную.
Возьмите/купите одну из готовых систем репликации под Firebird - будет
дешевле и быстрее, чем изобретать велосипед.
Может
А по моему лучше в триггерах накапливать изменения, а репликацию делать
в отдельном потоке.
Добрый день!
Возможность выполнять EXECUTE STATEMENT на другой базе
позволяет легко реализовать надежную схему односторонней
онлайн репликации.
Но, вся засада в том, что коннект к базе открывается
каждый раз при выполнении оператора. Мы собрали у себя тестовый пример.
Изменения без репликации
A K wrote ...
Добрый день!
Возможность выполнять EXECUTE STATEMENT на другой базе
позволяет легко реализовать надежную схему односторонней
онлайн репликации.
Но, вся засада в том, что коннект к базе открывается
каждый раз при выполнении оператора. Мы собрали у себя тестовый пример.
Изменения
On 01.07.2011 19:47, A K wrote:
Попробуйте выталкивать изменения не по каждому I\U\D а по коммиту
тр-ции.
А что это изменит? Все равно каждый EXECUTE STATEMENT будет
открывать-закрывать подключение к БД. Только что подвисать будет не
каждая операция, а комит транзакции.
Транзакций
Транзакций существенно меньше чем CRUD операций как правило.
я понимаю, что в общем случае их будет меньше. Но, например, накопил я
в логе десять изменений в разных таблицах. Идет комит транзакции.
Мне все равно придется выполнить десять EXECUTE STATEMENT к внешней
базе, причем каждый
Hello, Arioch!
Arioch wrote:
http://web.archive.org/web/20041009184946/http://ibase.ru/v6/conf/conf.htm
Во-первых, они уже никаким образом не относятся к FIDO :-)
Во-вторых, в них чётко прописано, что нужно включать MIME для MS OE :-)
Хоррроший документ :-D
из этого документа, кстати, явно
27.06.2011 21:47, Alexey Popov пишет:
1) Внутрь сервера яву никто не тянет, там лишь интерфейс к ней.
Остальное снаружи в плагинах. Опционально.
Это вопрос технический - где будет работать JVM.
Однако тенденция неприятная.
UDF тоже неприятная тенденция? Если нет, то в чем отличие?
2)
Tonal wrote ...
24.06.2011 13:49, Khorsun Vlad пишет:
EB вполне устраивает.
Он не будет рекурсивным.
Этому есть какие-то причины теоретического плана или технического?
Нет конечно, это мой каприз.
Мне казалось, что ЕБ ничем от сохранёнки не отличаются кроме наличия
имени. Если это
Наверняка. И не обязательно связанные с рекурсией и с CTE. Например, можно
вынести связи в отдельную таблицу и писать туда не только пары
непосредственных
parent\child, но и вообще всех child'ов данного parent'а. Другой подход
описания
дерева с помощью границ множеств есть у Celko (и у DK
Алексей Вишняков ...
Наверняка. И не обязательно связанные с рекурсией и с CTE. Например, можно
вынести связи в отдельную таблицу и писать туда не только пары
непосредственных
parent\child, но и вообще всех child'ов данного parent'а. Другой подход
описания
дерева с помощью границ множеств есть у
Ой, а можно ссылочку на сайт, пожалуйста? Я бы почитал, интересно.
Это шутка такая ? :-D Как можно не знать про www.ibase.ru ?
Я думал, на выделенном каком-то сервере.
Строго говоря, я в последнее время птице изменил, на мс скл ковыряюсь.
Но концепции-то везде одинаковые.
Смотри здесь
В письме от Tue, 28 Jun 2011 09:46:57 +0400, Tonal
to...@promsoft.ru сообщал:
Мне казалось, что ЕБ ничем от сохранёнки не отличаются кроме наличия
имени.
вообще, даже если бы так, это была бы не лямбда, а просто анонимная
функция.
не знаю как в высокой теории, но так на пальцах вроде
Здравствуйте, Arioch.
Вы писали 28 июня 2011 г., 0:10:57:
В письме от Mon, 27 Jun 2011 20:18:58 +0400, Alexey Popov
a...@novgorod.net сообщал:
В больших проектах совсем другое ставиться во главу угла, а не сколько
там синтаксического сахара в языке.
а FB действительно нужны БОЛЬШИЕ
Здравствуйте, Vlad.
Вы писали 28 июня 2011 г., 14:49:22:
У меня к тебе никаких претензий нет, даже наоборот - ты оживил эту
конференцию,
за что и спасибо :) Провокатором неоднократно выступает Yurij и я каждый раз
сожалею
о том, что что-то ему отвечаю. Ибо потом, после чтения его
В письме от Thu, 23 Jun 2011 06:42:24 +0400, Кравченко Алексей
ista...@ngs.ru сообщал:
если бы он перестраивался, наверное, ты бы не жаловался, что альтер
слишком быстро прошел :-)
я полагаю что при наличии индекса и других зависимостей alter просто не
выполнится
не знаю, как насчёт
В письме от Fri, 24 Jun 2011 22:38:12 +0400, Владимир Аксенов
fr...@academ.org сообщал:
Вообще-то и Линукса тогда вообще не было.
Договоренность про KOI8-R была еще в FIDO7.SU.DBMS.INTERBASE
это как ? в FIDO эе стандарт досовская кодировка, ibm866 ?
через гейт-то понятно, что переводили в
В письме от Fri, 24 Jun 2011 16:12:21 +0400, Khorsun Vlad
hv...@optima.com.ua сообщал:
т.е. если оно не исчезнет через год-два-три, возможно посмотрю
пристальнее.
ну в высоконагруженных сильнопараллельных программах оно существует уже не
год-три, Erlang и написанные под его влиянием
Здравствуйте, Arioch.
Вы писали 27 июня 2011 г., 18:08:55:
Вообще-то и Линукса тогда вообще не было.
Договоренность про KOI8-R была еще в FIDO7.SU.DBMS.INTERBASE
это как ? в FIDO эе стандарт досовская кодировка, ibm866 ?
через гейт-то понятно, что переводили в koi8-r, но это была
Здравствуйте, Arioch.
Вы писали 27 июня 2011 г., 18:08:55:
через гейт-то понятно, что переводили в koi8-r, но это была договорённость
Демоса с самим собой, РАЗВЕ ЕТ ? :-)
Ради интереса покопался в инете - нашел правила конференции на эпсилон.
Правила были размещены тут, но сейчас их там нет,
Arioch wrote ...
В письме от Fri, 24 Jun 2011 16:12:21 +0400, Khorsun Vlad сообщал:
т.е. если оно не исчезнет через год-два-три, возможно посмотрю пристальнее.
ну в высоконагруженных сильнопараллельных программах оно существует уже не год-три, Erlang и написанные под его влиянием
Действительно, очень актуальная и полезная информация. Не могу поспорить...
27 июня 2011 г. 16:11 пользователь Владимир Аксенов fr...@academ.org написал:
Здравствуйте, Arioch.
Вы писали 27 июня 2011 г., 18:08:55:
через гейт-то понятно, что переводили в koi8-r, но это была договорённость
Здравствуйте, Алексей.
Вы писали 27 июня 2011 г., 19:25:00:
Действительно, очень актуальная и полезная информация. Не могу поспорить...
Да я вижу что тебе не помогли.
Оверквотинг, цитирование подписи, ответ перед цитатой.
Куда катится мир...
--
С уважением,
Владимир
В письме от Mon, 27 Jun 2011 16:11:50 +0400, Владимир Аксенов
fr...@academ.org сообщал:
А вот так выглядели эти правила в 2004 году :)
http://web.archive.org/web/20041009184946/http://ibase.ru/v6/conf/conf.htm
Во-первых, они уже никаким образом не относятся к FIDO :-)
Во-вторых, в них
Действительно, очень актуальная и полезная информация. Не могу поспорить...
Да я вижу что тебе не помогли.
Оверквотинг, цитирование подписи, ответ перед цитатой.
Стандартная настройка гмыла, угу. И лень поубирать лишнее.
С уважением, Алексей Вишняков.
Yurij wrote:
А как вы относитесь к функциональному программированию и около него
вообще?
Функциональное это слишком широкий термин. Функционально можно и на
голом C писать.
Если смотреть на SQL, то это типичный DSL. Но неплохо бы добавить
возможность определять локальные иммутабельные
Arioch wrote:
ну в высоконагруженных сильнопараллельных программах оно существует уже
не год-три,
Там рулят в основном C++, фортран и кобол. Увы.
Erlang и написанные под его влиянием библиотеки.
Erlang это прежде всего узкоспециализированный RTL, язык там дело десятое.
Vlad Khorsun wrote:
Я не собираюсь продолжать эту беседу ибо она была спровоцированна с
единственной целью - поржать в ЖЖ над частично процитированным и оторванным
от контекста моим частным мнением. Выставляя косным идиотом не только
меня (на
это мне наплевать), но и Firebird вместе со
27.06.2011 20:27, Alexey Popov пишет:
Тем не менее люди с нетрадиционной сексуальной ориентацией тянут внутрь
сервера Яву и прочую гомосятину. А нормального супер сервера как не было
так и нет :(
1) Внутрь сервера яву никто не тянет, там лишь интерфейс к ней.
Остальное снаружи в плагинах.
27.06.2011 20:18, Alexey Popov пишет:
Если смотреть на SQL, то это типичный DSL. Но неплохо бы добавить
возможность определять локальные иммутабельные переменные-множества типа:
x=select * from table
select * from x;
Это существенно упростит декомпозицию многоэтажных запросов и улучшит
В письме от Mon, 27 Jun 2011 20:23:08 +0400, Alexey Popov
a...@novgorod.net сообщал:
Erlang и написанные под его влиянием библиотеки.
Erlang это прежде всего узкоспециализированный RTL, язык там дело
десятое.
таки язык и дал возможность сделать такую RTL, и в других похожих
В письме от Mon, 27 Jun 2011 20:18:58 +0400, Alexey Popov
a...@novgorod.net сообщал:
В больших проектах совсем другое ставиться во главу угла, а не сколько
там синтаксического сахара в языке.
а FB действительно нужны БОЛЬШИЕ проекты ?
мне казалось, скорее малые и средние.
--
Написано в
Dmitry Yemanov wrote:
1) Внутрь сервера яву никто не тянет, там лишь интерфейс к ней.
Остальное снаружи в плагинах. Опционально.
Это вопрос технический - где будет работать JVM.
Однако тенденция неприятная.
2) Нормальный суперсервер есть в той же версии, что и ненавистная тебе
ява. Если ты
Dmitry Yemanov wrote:
Если смотреть на SQL, то это типичный DSL. Но неплохо бы добавить
возможность определять локальные иммутабельные переменные-множества типа:
x=select * from table
select * from x;
Это существенно упростит декомпозицию многоэтажных запросов и улучшит
читабельность.
Ну и
В письме от Mon, 27 Jun 2011 20:37:28 +0400, Dmitry Yemanov
dim...@users.sf.net сообщал:
1) Внутрь сервера яву никто не тянет, там лишь интерфейс к ней.
в принципе, если такой плагин или плагин-UDF может на вход получать курсор
(чтобы не перечислять явно поля в запросе), то вот она и
28.06.2011 00:58, Alexey Popov пишет:
Честно говоря не обдумывал насколько CTE мощно в этом плане. Возможно
неудачный синтаксис виноват. Ну например сделать что то типа такого:
x=select ...
y=select ...
z=select ...
select * from x,y,z
with [recursive]
x as (select ...)
y as (select ...)
Vlad Khorsun пишет:
Про какой-то installation_scripted.txt встречаются описания.
Но не нахожу его ни в линуховом tar'е (а чего бы ему там и правда
делать-то?..), ни в виндовом zip-ките (а вот
это странно).
в /builds/install/arch-specific/win32/ смотрел ?
О, чудо! :)
Спасибо, Влад! Я ж
24.06.2011 13:49, Khorsun Vlad пишет:
EB вполне устраивает.
Он не будет рекурсивным.
Этому есть какие-то причины теоретического плана или технического?
Нет конечно, это мой каприз.
Мне казалось, что ЕБ ничем от сохранёнки не отличаются кроме наличия
имени. Если это так, тогда
Tonal wrote in message ...
23.06.2011 20:58, Vlad Khorsun пишет:
Пиши процедуры для таких задач. По-хорошему советую :)
EB вполне устраивает.
Он не будет рекурсивным.
Этому есть какие-то причины теоретического плана или технического?
Нет конечно, это мой каприз.
Но без
23.06.2011 22:02, Владимир Аксенов пишет:
Людей не путай.
В русскоязычных ньюсах хороший тон или стандарт по факту - KOI8-R по
умолчанию
нет.
За все конфы отвечать не буду, но в этой - именно что да.
Да, - сказал Владимир, и отправил пост в charset=Windows-1251...
Alex Cherednichenko пишет:
Людей не путай.
В русскоязычных ньюсах хороший тон или стандарт по факту - KOI8-R по умолчанию
нет.
За все конфы отвечать не буду, но в этой - именно что да.
Да, - сказал Владимир, и отправил пост в charset=Windows-1251...
Он его явно задал _явно_. А мы тут об
Может, мы о разных вещах говорим?
Я настаиваю на том, что если заголовок (например Subject) входящего сообщения
8-битный (и кодировка не указана), то клиентское ПО должно предполагать для
этого заголовка кодировку KOI8-R.
Этого КМК придерживается большинство достаточно старых ньюсов.
Про всех
24.06.2011 13:03, М.Королев пишет:
Он его явно задал _явно_. А мы тут об умолчаниях.
Нету никаких умолчаний.
Кодировка всегда должна указываться.
Кто этого не делает - плюет на окружающих.
Alex Cherednichenko пишет:
24.06.2011 13:03, М.Королев пишет:
Он его явно задал _явно_. А мы тут об умолчаниях.
Нету никаких умолчаний.
Кодировка всегда должна указываться.
Кто этого не делает - плюет на окружающих.
Это эмоции. Жизнь богаче.
Hello, М. Королев!
М.Королев wrote:
Может, мы о разных вещах говорим?
Я настаиваю на том, что если заголовок (например Subject) входящего
сообщения 8-битный (и кодировка не указана), то клиентское ПО должно
предполагать для этого заголовка кодировку KOI8-R.
Этого КМК придерживается
Alex Cherednichenko пишет:
Это RFC-2047.
Опять 25.
RFC-2047 - это описание синтаксиса MIME-заголовков,
а не статья УК за его неиспользование.
Нету никаких умолчаний.
По жизни - есть посты без указания кодировки для 8-битного заголовка.
Кодировка всегда должна указываться.
Но указывается не
24.06.2011 14:15, М.Королев пишет:
Опять 25.
RFC-2047 - это описание синтаксиса MIME-заголовков,
а не статья УК за его неиспользование.
Там обрыв. Но вам туда можно.
Alex Cherednichenko пишет:
Опять 25.
RFC-2047 - это описание синтаксиса MIME-заголовков,
а не статья УК за его неиспользование.
Там обрыв. Но вам туда можно.
Хороший был юморист.
Предлагаю завязать.
В письме от Fri, 24 Jun 2011 10:49:38 +0400, Khorsun Vlad
hv...@optima.com.ua сообщал:
Нет, мы выяснили что есть for with recursive который позволяет не
писать процедуру (А ЧЕМ ПЛОХО ПИСАТЬ ПРОЦЕДУРУ ???)
stack overflow :-)
Для процедуры он должен раньше наступить, чем просто для for.
Arioch ...
В письме от Fri, 24 Jun 2011 10:49:38 +0400, Khorsun Vlad сообщал:
Нет, мы выяснили что есть for with recursive который позволяет не
писать процедуру (А ЧЕМ ПЛОХО ПИСАТЬ ПРОЦЕДУРУ ???)
stack overflow :-)
Пальцем в небо. Давай не будем делать предположений за других.
--
PS Не удивлюсь, если ты окажешься фанатом новомодных лямбда ф-ций (чи как
их там - когда тело ф-ции пишут в месте её вызова, без объявления) :-D
а чем плохо? лямбда функции (в виде рекурсивных EB) стали бы
конкурентным преимуществом сервера и замечательной темой для
рекламы.
A K ...
PS Не удивлюсь, если ты окажешься фанатом новомодных лямбда ф-ций (чи как
их там - когда тело ф-ции пишут в месте её вызова, без объявления) :-D
а чем плохо? лямбда функции (в виде рекурсивных EB) стали бы
конкурентным преимуществом сервера и замечательной темой для
рекламы.
Vladimir A.Bakhvaloff пишет:
On Fri, 24 Jun 2011 15:12:46 +0400, М.Королев
mia...@mail.ru wrote:
Alex Cherednichenko пишет:
Там обрыв. Но вам туда можно.
Хороший был юморист.
Предлагаю завязать.
Ты за что это Семёна Теодоровича хоронишь-то??? 8-О
Эээ... Виноват-с! Неаккуратно выразился.
On Jun 24, 2:57 pm, Khorsun Vlad hv...@optima.com.ua wrote:
Отвратительная возможность, провоцирующая написание нечитаемого
и несопровождаемого спагетти-кода, созданная на пустом месте чисто в
маркетинговых целях.
Вот такое моё частное мнение о лямбда-функциях.
А как вы относитесь к
Arioch пишет:
В письме от Fri, 24 Jun 2011 14:15:44 +0400, М.Королев
mia...@mail.ru сообщал:
Нету никаких умолчаний.
По жизни - есть посты без указания кодировки для 8-битного заголовка.
По жизни на улицах вокруг урн мусор валяется.
Есть, с этим надо считаться, но не надо самому так делать.
Yurij ...
А как вы относитесь к функциональному программированию и около него
вообще? Ну там функции высшего порядка, всякая там строгая типизация,
вариантные типы данных и прочее тому подобное?
Когда-то давно, лет 8 назад, что-то читал на эту тему, ни ничего не
пробовал. Да тогда и не
24.06.2011 16:06, Yurij пишет:
А как вы относитесь к функциональному программированию и около него
вообще? Ну там функции высшего порядка, всякая там строгая типизация,
вариантные типы данных и прочее тому подобное?
а СУБД тут каким боком?
On Jun 24, 3:13 pm, Alex Cherednichenko cheredniche...@post.cz
wrote:
24.06.2011 16:06, Yurij :
А как вы относитесь к функциональному программированию и около него
вообще? Ну там функции высшего порядка, всякая там строгая типизация,
вариантные типы данных и прочее тому подобное?
а СУБД тут
а СУБД тут каким боком?
современные тенденции -- сближение технологий. LINQ, всяческие ОО
маппинги для баз данных и т.п. тому примером.
24.06.2011 17:28, A K пишет:
современные тенденции -- сближение технологий.
LINQ, всяческие ОО
ихний LINQ - жалкое подобие нашего GPRE!
Alex Cherednichenko ...
24.06.2011 17:28, A K пишет:
современные тенденции -- сближение технологий.
LINQ, всяческие ОО
ихний LINQ - жалкое подобие нашего GPRE!
+100500
--
Хорсун Влад
On Jun 24, 3:36 pm, Alex Cherednichenko cheredniche...@post.cz
wrote:
24.06.2011 17:28, A K :
современные тенденции -- сближение технологий.
LINQ, всяческие ОО
ихний LINQ - жалкое подобие нашего GPRE!
В GPRE строгая типизация и монады есть?:)
Yurij ...
On Jun 24, 3:36 pm, Alex Cherednichenko wrote:
24.06.2011 17:28, A K :
современные тенденции -- сближение технологий.
LINQ, всяческие ОО
ихний LINQ - жалкое подобие нашего GPRE!
В GPRE строгая типизация
Да
и монады есть?:)
Понятия не имею.
--
Хорсун Влад
и монады есть?:)
Понятия не имею.
короче, всем пора выпить лимонаду. тем более пятница.
если рекурсивные EB можно сделать, то это было бы
весьма неплохо.
что до общего тона дискуссии, то имея на руках проект
в 1.6М строк кода на Д5, меня тоже раздражает, когда натыкаюсь
на дискуссии о
Здравствуйте, Arioch.
Вы писали 24 июня 2011 г., 18:16:24:
Кто этого не делает - плюет на окружающих.
Не плюет, если кодирует в KOI8-R.
Потому что об этом де факто договорились в девяносто мохнатом году.
1) Я не договаривался. У меня тогда Линукса не было.
Вообще-то и Линукса тогда
Здравствуйте, Dmitri.
Вы писали 24 июня 2011 г., 16:28:14:
Ньюсридеров российских нет, группа эта тоже не российская,
так что умолчаний никаких нет (вернее, у группы задан 1251 для веба,
но не более того).
Ньюсридеры это конечно больная тема, но я эту конфу пишу и читаю через родной
мыльный
Tonal ...
Почему бы не ввести специальную конструкцию, для вызова из блока самого себя?
Почему бы не пользоваться рекурсивными CTE ?
--
Хорсун Влад
22.06.2011 18:17, Arioch пишет:
например у вас есть varchar = O001 - букву вместо нолика, бывает.
alter varchar - integer отработает.
Да неужели.
Новость хорошая.
Тогда бы было хорошо FAQ обновить, какие проверки и когда выполняются в
актуальных версиях.
Актуальные версии тут не причем.
В письме от Thu, 23 Jun 2011 11:15:57 +0400, Dmitry Yemanov
dim...@users.sf.net сообщал:
Актуальные версии тут не причем. Оно никогда не работало.
грохнется на перестройке индекса ?
ok, ладно, я перестраховщик. Привык что это опасно, и предпочитаю думать
хуже, чем оно есть.
но жаль,
Результаты 401 - 500 из 33066 matches
Mail list logo
