F>хотя что переносить? локальный базы используются только для разработки и прогона тестов. дальше всё уходит на промежуточный сервант с той субд, которая будет на продавшоне.
Я правильно понимаю, что Вы считаете нормальным тестировать систему с одной СУБД, а в продакшене использовать другую? Рисковый Вы человек.
Здравствуйте, neFormal, Вы писали:
F>нет, я считаю нормальным разрабатывать с одной СУБД под ORM, а тестировать силами QA и пускать в продавшон с другой. F>под прогоном тестов я имею в виду tdd/bdd. с orm действительно пофиг, что за субд используется.
До первого бага в реализации ORM под конкретную СУБД. После этого получаем кучу секса с удаленной идентификацией проблемы. А если учитывать встречающийся уровень забюрократизированности доступа дева даже к QA, то вообще пиши пропал.
Здравствуйте, Zenden, Вы писали:
Z>Здравствуйте, Grienders, Вы писали:
G>>По-сравнению с Rails.
Z>Потому что питон. Там всё через ж. Взять хотя бы отступы.
Здравствуйте, neFormal, Вы писали:
F>локальные базы удобней. не захламляется общая субд. F>сегодня у тебя один проект, завтра другой, послезавтра третий. F>и там не только код меняется, но и база, версия языка, набор библиотек и прочее-прочее. F>там и тесты удобно гонять, когда надо сгенерить базу.
F>>всё верно. "встроенные решения" обычно слабее нормальной субд, поэтому там сразу почувствуется лажа. Ops>И начнется преждевременная оптимизация
Причем совершенно неочевидная — вполне есть сценарии, когда sqlite даже на более слабом железе выигрывает у postgres. Что логично — используются разные алгоритмы, дающие различную эффективность на разных наборах данных.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Grienders, Вы писали:
G>По-сравнению с Rails.
Вот-вот, у меня тот же вопрос.
В рельсах я как-то сразу послал нафиг ORM и писал запросы к базе руками. Соответственно, на модельном уровне завёл функции в классе модельки, которые возвращают нужное (ну или сохраняют нужное). Завёл в базе нужные триггеры и вьюхи для того, чтобы хранилось всё как надо.
Как по-человечески в django сделать пользовательскую аутентификацию, отличную от их встроенной, я так и не понял — буду переписывать с нуля, отвязываясь от django-users вообще.
Почему-то пакет с, простите, bootstrap что-то ставит в питоновые исходники, хотя это же чистый сss/javascript!
А, да, ORM — немыслимое днище, что в Rails, что в Django. Придумано для тех Кумаров, которые не смогли понять, как писать SQL-запросы по-человечески?
Здравствуйте, Dair, Вы писали:
D>В рельсах я как-то сразу послал нафиг ORM и писал запросы к базе руками. Соответственно, на модельном уровне завёл функции в классе модельки, которые возвращают нужное (ну или сохраняют нужное). Завёл в базе нужные триггеры и вьюхи для того, чтобы хранилось всё как надо. D>А, да, ORM — немыслимое днище, что в Rails, что в Django. Придумано для тех Кумаров, которые не смогли понять, как писать SQL-запросы по-человечески?
Здравствуйте, Grienders, Вы писали:
G>>>По-сравнению с Rails. Z>>Потому что питон. Там всё через ж. Взять хотя бы отступы. G>C Питоном как раз проблем нет.
Ой, только не надо ля ля. С питоном всё те же проблемы что и со всеми остальными языками — его надо знать в довесок ко всему остальному что уже знаешь. И те же проблемы что с линуксом — ты его будешь знать каждый день.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Grienders, Вы писали:
G>По-сравнению с Rails.
В rails типа все нормально?
Вчера сексом занимался наночь глядя.
Замечательноая ошибка:
rake aborted! "cannot load such file -- iconv"
хотя у меня:
D:\>iconv --version
iconv (GNU libiconv 1.9)
Copyright (C) 2000-2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Bruno Haible.
В итоге забил на это УГ. Использовал альтернативный способ сборки.
Да и вопрос нагрена существует rubi версии 2.2? После секска находишь кучу советов ставить версию 2.1.
А то что на rubi есть кучу зависимостей, которые тупо под Windows не поддерживаются?
По опыту вижу, что в настоящее время ничего лучше чистого С (posix стандарт) и Java (если Java поддерживается платформой) нет, в плане кросс-платформености.
Здравствуйте, 31415926, Вы писали:
3>Ну например в том, что существует такая вещь, как "общая БД". Т.е. логически конечно можно такое организовать, но зачем? Вот в компании, на которую я сейчас работаю, на тестовом стенде запускается отдельный PG кластер для каждого пользователя. А как правило вполне достаточно иметь один сервер с разными базами.
заводить свою личную БД в общей системе как-то не очень. за ними надо следить.
я скорее сторонник полного цикла у каждого кодера на машине. если, конечно, это позволяет технология.
Здравствуйте, neFormal, Вы писали:
F>потому что: F>1. она маленькая F>2. привязана к проекту F>3. её можно удалить просто через rm F>4. создание базы и заполнение начальными данными происходит при запуске тестов или отдельной командой самим разработчиком F>5. не надо напрягать админа следить за базами на общем серваке
Что такое "маленькая" я не понимаю. У меня как-то на ноутбуке одновременно работали MS SQL, Oracle и UDB DB2. Все остальное тоже выглядит странновато. Все это без проблем делается с любой известной мне СУБД (разве что удаление одним rm не обойтись, но вызовом скрипта из максимум десятка строк — запросто).
F>всё верно. "встроенные решения" обычно слабее нормальной субд, поэтому там сразу почувствуется лажа.
Бывает, что и наоборот.
F>ну и не забываем, что это всё работает в простых случаях. F>там, где из субд надо выжать максимум её возможностей, это не будет работать. F>а в вебе и прочих бэкендах это норм. с маянезиком.
Возможно. У меня опыта с настолько простыми случаями нет. Хотя Кумары именно такими и занимаются. А маянезик не очень полезен для здоровья.
Здравствуйте, neFormal, Вы писали:
F>такие вещи выясняются при первом деплое на тестовое железо.
Не всегда при первом. Часто при каких-то изменениях может вылезти что-то новое. F>повторюсь, как в соседней ветке, это удобно в основном на несложном вебе. там выжимать из субд всё не требуется.
Удобно как раз работать с тем окружением, которое будет в продакшене, пусть это и простой веб. Тогда неожиданностей будет мало.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, 31415926, Вы писали:
3>Видите ли. Я работал в одной (не самой последней) московской компании, где у разработчиков вообще не было заведено тестировать свой код. Даже не всегда перед коммитом проверяли, что проект компилируется. Так что там было состояние перманентой неожиданности и это никого не смущало (так сказать — привычный запор). Видимо наш собеседник работает примерно в такой же. Само по себе это может быть и ничего. Только вот разговоры о переходе на исключительно российский софт смотрятся немного смешно.
какие нажористые у тебя тараканы.
и это при том, что я говорю как раз про тестирование.
Здравствуйте, Sheridan, Вы писали:
F>>но ведь это киллер-фича. языки без отступов только для тех, кто не осилил выучиться на художника.
S>Именно тем, которые осилили выучится на художника, даются чистые листы бумаги.
А тем, кто научился плавать, наливают воду в бассейн.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Grienders, Вы писали:
G>>По-сравнению с Rails.
S>Потому что изначально вкурен райлс, похоже. Был бы вкурен сначала джанга — вопрос был бы зеркален
Да нифига. Простое поле к модели добавить, чтобы по нему фильтровать — проблема. Вызвать метод со скобками в .html — проблема. Да и еще куча всего.
Здравствуйте, Dair, Вы писали:
D>А, да, ORM — немыслимое днище, что в Rails, что в Django. Придумано для тех Кумаров, которые не смогли понять, как писать SQL-запросы по-человечески?
Это да. Впрочем, вроде бы считается, что это можно использовать для того, чтобы приложение могло работать с несколькими БД. У меня есть сомнения, что это в самом деле работает (кроме совсем простых случаев), но я могу ошибаться. Кроме того, я не знаю, насколько часто это реально нужно.
Здравствуйте, 31415926, Вы писали:
3>Это да. Впрочем, вроде бы считается, что это можно использовать для того, чтобы приложение могло работать с несколькими БД. У меня есть сомнения, что это в самом деле работает (кроме совсем простых случаев), но я могу ошибаться. Кроме того, я не знаю, насколько часто это реально нужно.
Как я где-то прочитал, "работа с несколькими БД — это как секс у подростков — чаще говорят, чем делают".
И, да, оно сгенерит неоптимальные запросы, но к разным БД. Не лучше чем это сделаю я под конкретную БД. Например, внося в селект лишние (не нужные мне сейчас) поля. Ну это не говоря уже о запросах более сложных чем select ... from a,b,c where ... order by ...
Как на ORM делают outer join? как делают select from select? Как делают insert returning?
Здравствуйте, 31415926, Вы писали:
3>Это да. Впрочем, вроде бы считается, что это можно использовать для того, чтобы приложение могло работать с несколькими БД. У меня есть сомнения, что это в самом деле работает (кроме совсем простых случаев), но я могу ошибаться. Кроме того, я не знаю, насколько часто это реально нужно.
с несколькими субд?
да, это частенько используют там, где не требуются особые фичи какой-то субд.
например, в разработке берут sqlite, а для продавшона уже какой-нибудь postgresql.
Здравствуйте, Dair, Вы писали:
D>Как я где-то прочитал, "работа с несколькими БД — это как секс у подростков — чаще говорят, чем делают".
D>И, да, оно сгенерит неоптимальные запросы, но к разным БД. Не лучше чем это сделаю я под конкретную БД. Например, внося в селект лишние (не нужные мне сейчас) поля. Ну это не говоря уже о запросах более сложных чем select ... from a,b,c where ... order by ...
D>Как на ORM делают outer join? как делают select from select? Как делают insert returning?
Так и я не знаю. Мне как-то пришлось добавлять к довольно большому приложению поддержку Oracle и DB2 (был MS SQL). Сделали "руками" примерно за месяц.
Здравствуйте, 31415926, Вы писали:
F>>например, в разработке берут sqlite, а для продавшона уже какой-нибудь postgresql. 3>А вот такого подхода я категорически не понимаю? Зачем?
локальные базы удобней. не захламляется общая субд.
сегодня у тебя один проект, завтра другой, послезавтра третий.
и там не только код меняется, но и база, версия языка, набор библиотек и прочее-прочее.
там и тесты удобно гонять, когда надо сгенерить базу.
в продавшоне гетерогенность субд тоже встречается, но довольно редко.
Здравствуйте, neFormal, Вы писали:
F>а конкретней можно? F>может я действительно фатально ошибаюсь. хотелось бы знать, в чём именно.
Ну например в том, что существует такая вещь, как "общая БД". Т.е. логически конечно можно такое организовать, но зачем? Вот в компании, на которую я сейчас работаю, на тестовом стенде запускается отдельный PG кластер для каждого пользователя. А как правило вполне достаточно иметь один сервер с разными базами.
Здравствуйте, Ops, Вы писали:
F>>локальные базы удобней. не захламляется общая субд. Ops>Что мешает поставить ПГ локально? Она довольно легкая. При этом сильно отличается от sqlite, что может вылиться в интересный секс при переносе.
orm скрывает всю расчленёнку от кодера. таким образом человек работает только с неким подмножеством всех доступных субд.
и тут уже никакого интима при переносе.
хотя что переносить? локальный базы используются только для разработки и прогона тестов. дальше всё уходит на промежуточный сервант с той субд, которая будет на продавшоне.
Здравствуйте, 31415926, Вы писали:
3>Я правильно понимаю, что Вы считаете нормальным тестировать систему с одной СУБД, а в продакшене использовать другую?
нет, я считаю нормальным разрабатывать с одной СУБД под ORM, а тестировать силами QA и пускать в продавшон с другой.
под прогоном тестов я имею в виду tdd/bdd. с orm действительно пофиг, что за субд используется.
Здравствуйте, neFormal, Вы писали:
F>orm скрывает всю расчленёнку от кодера. таким образом человек работает только с неким подмножеством всех доступных субд. F>и тут уже никакого интима при переносе.
Например, постгрес по-умолчанию не поддерживает имена идентификаторов длиннее 63 символов, чтобы увеличить нужно пересобирать. Насчет sqlite не знаю, а мускул умеет гораздо длиннее. Вот тебе и возможный секс
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
F>нет, я считаю нормальным разрабатывать с одной СУБД под ORM, а тестировать силами QA и пускать в продавшон с другой. F>под прогоном тестов я имею в виду tdd/bdd. с orm действительно пофиг, что за субд используется.
Зачем использовать другую СУБД для разработки и первичного тестирования? А насчет "пофиг" имеются сильные сомнения. Как минимум, в отношении производительности.
Здравствуйте, 31415926, Вы писали:
3>Зачем использовать другую СУБД для разработки и первичного тестирования?
потому что:
1. она маленькая
2. привязана к проекту
3. её можно удалить просто через rm
4. создание базы и заполнение начальными данными происходит при запуске тестов или отдельной командой самим разработчиком
5. не надо напрягать админа следить за базами на общем серваке
3>А насчет "пофиг" имеются сильные сомнения. Как минимум, в отношении производительности.
всё верно. "встроенные решения" обычно слабее нормальной субд, поэтому там сразу почувствуется лажа.
ну и не забываем, что это всё работает в простых случаях.
там, где из субд надо выжать максимум её возможностей, это не будет работать.
а в вебе и прочих бэкендах это норм. с маянезиком.
Здравствуйте, Ops, Вы писали:
Ops>Например, постгрес по-умолчанию не поддерживает имена идентификаторов длиннее 63 символов, чтобы увеличить нужно пересобирать. Насчет sqlite не знаю, а мускул умеет гораздо длиннее. Вот тебе и возможный секс
такие вещи выясняются при первом деплое на тестовое железо.
повторюсь, как в соседней ветке, это удобно в основном на несложном вебе. там выжимать из субд всё не требуется.
Здравствуйте, neFormal, Вы писали:
F>потому что: F>1. она маленькая
Ну я хз даже, несколько МБ не жмут. F>2. привязана к проекту
В чем разница? F>3. её можно удалить просто через rm
на 4 буквы короче, чем dropdb, аргумент. F>4. создание базы и заполнение начальными данными происходит при запуске тестов или отдельной командой самим разработчиком
В чем разница? F>5. не надо напрягать админа следить за базами на общем серваке
Зачем на общем? Локально же.
F>всё верно. "встроенные решения" обычно слабее нормальной субд, поэтому там сразу почувствуется лажа.
И начнется преждевременная оптимизация
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
F>>2. привязана к проекту Ops>В чем разница?
проекты меняются чаще, чем перчатки.
ну и не всегда известно, на чём будет сидеть клиент.
F>>4. создание базы и заполнение начальными данными происходит при запуске тестов или отдельной командой самим разработчиком Ops>В чем разница?
не нужен локальный сервант. для лёгкого веба это самое то.
для более сложных вариантов разницы уже нет.
F>>5. не надо напрягать админа следить за базами на общем серваке Ops>Зачем на общем? Локально же.
когда проектов несколько, то появляется несколько разных субд локально.
не самый приятный вариант.
с другой стороны у меня сейчас один pgsql используется с чистым sql. и с несколькими шардами в нём.
вот там хрен угадаешь, на каком шарде сидит юзер. а с несколькими конфигурациями или проектами это становится ещё сложнее.
проще работать с БД через orm. там пофиг, кто, где и через что. всё прячется за ширмой orm.
F>>всё верно. "встроенные решения" обычно слабее нормальной субд, поэтому там сразу почувствуется лажа. Ops>И начнется преждевременная оптимизация
Здравствуйте, 31415926, Вы писали:
3>Возможно. У меня опыта с настолько простыми случаями нет. Хотя Кумары именно такими и занимаются. А маянезик не очень полезен для здоровья.
Здравствуйте, Ops, Вы писали:
Ops>Удобно как раз работать с тем окружением, которое будет в продакшене, пусть это и простой веб. Тогда неожиданностей будет мало.
Видите ли. Я работал в одной (не самой последней) московской компании, где у разработчиков вообще не было заведено тестировать свой код. Даже не всегда перед коммитом проверяли, что проект компилируется. Так что там было состояние перманентой неожиданности и это никого не смущало (так сказать — привычный запор). Видимо наш собеседник работает примерно в такой же. Само по себе это может быть и ничего. Только вот разговоры о переходе на исключительно российский софт смотрятся немного смешно.
Здравствуйте, neFormal, Вы писали:
G>>>По-сравнению с Rails. Z>>Потому что питон. Там всё через ж. Взять хотя бы отступы. F>но ведь это киллер-фича. языки без отступов только для тех, кто не осилил выучиться на художника.
Именно тем, которые осилили выучится на художника, даются чистые листы бумаги.
Здравствуйте, neFormal, Вы писали:
D>>В рельсах я как-то сразу послал нафиг ORM и писал запросы к базе руками. Соответственно, на модельном уровне завёл функции в классе модельки, которые возвращают нужное (ну или сохраняют нужное). Завёл в базе нужные триггеры и вьюхи для того, чтобы хранилось всё как надо. D>>А, да, ORM — немыслимое днище, что в Rails, что в Django. Придумано для тех Кумаров, которые не смогли понять, как писать SQL-запросы по-человечески?
F> F>тогда тебе ещё библиотеки не нужны.
Если библиотеки делают примерно такое (С++, вымышленная в вакууме)
template <typename T>
T mycoollibrary::multiply(T t1, T t2)
{
return t1 * t2;
}
То нет, не нужны.
Вот HTTP-запросы что рельсы, что django враппят нормально, более-менее удобно — этим я пользуюсь.
А вот на ORM сделать просто SQL-запрос — понятно, но чаще сама БД умеет оптимизировать запросы лучше чем это сделает ORM-движок, да и по памяти будет лучше соптимизировано. А ещё при большой загрузке так можно распределить загрузку с машины где веб-приложение на машину где сама БД.
Здравствуйте, Dair, Вы писали:
D>А ещё при большой загрузке так можно распределить загрузку с машины где веб-приложение на машину где сама БД.
но зачем?
D>А вот на ORM сделать просто SQL-запрос — понятно, но чаще сама БД умеет оптимизировать запросы лучше чем это сделает ORM-движок, да и по памяти будет лучше соптимизировано.
