Не будет никогда строгой типизации, потому что динамическая/нестрогая типизация — это ни хорошо и ни плохо, это просто динамическая/нестрогая типизация. Не нравится, есть миллион ЯП со строгой/статической типизацией.
Ну тогда уж рабочую лошадку + консоль + телевизор. Не будете же вы в самом деле играть на 15 дюймах. По деньгам такое сравнение совершенно неуместно: ваш вариант раза в 2 дороже как минимум.
Да никто не поливает грязью MySQL, это просто констатация факта, что MySQL морально устарел. Ну никаких аргументов за MySQL нет, кроме легаси. Ладно бы тут агитировали переход на MongoDB, это точно отдельный холиварный вопрос. Но PostgerSQL — это более функциональный товарищ MySQL. Нет ничего проще, чем начать новый проект на PostgreSQL. Синтаксис похож на 90%. А если вы используете хороший ORM, то разницы вообще не заметите. Зато получите из коробки кучу плюшек типа hstore, json, более информативные тексты ошибок, ну и вообще более оптимизированный движок, и в будущем гораздо меньше боли по масштабируемости.
phppgadmin, к сожалению, даже в подметки myAdmin-у не годится. А PgAdmin III больно древний, у меня какие-то проблемы с dll-ками на win8 есть, да и хочется «IDE», а не «Notepad++».
>> у Postgre web’е нет совершенно никаких решающих преимуществ
Ну у MySQL нет не то что решающих, а вообще никаких преимуществ. Все, что умеет MySQL, умеет и Postgre. Зато MySQL не умеет вагон того, что есть в Postgre. В пользу MySQL можно привести только чуть более мощную инфраструктуру (база знаний, вопросов, БД клиенты такие как Workbench и PHPmyAdmin).
>> Простой пример рассказа “Ваш старенький форум поддержки уже не справляется с наплывом посетителей, данные жалко, MySQL трещит по швам, дорабатывать сайт некому? «Тру» репликация PG вас спасет. Мы расскажем Вам как быстрее мигрировать”
Просто вставьте новую колонку в таблицу с 100кк записей.
А Doctrine научилась фильтровать по идентификатору внешнего ключа, не выгружая целиком весь связанный объект из БД? А также сетить идентификатор в relation вместо целого объекта?
— Пользователь вставляет 500 символов в колонку VARCHAR 255.
Ситуация 1: если БД ругается, то пользователь создает баг-репорт, отправляет разработчику, разработчик правит, работаем дальше.
Ситуация 2: БД не ругается, пользователь думает, что все норм. Далее еще полгода работа продолжается в таком же режиме. Затем, когда надо поднять информацию, оказывается, что половины данных нет. Все получают по шапке.
— Размерность поля на производительность, кажется, не оказывает практически никакого влияния.
— Насчет INSERT IGNORE и в правду не очень понятно, почему это плохо.
>> Если вас спрашивают — «доктор, сколько таблеток мне необходимо принимать?» — нельзя отвечать «необходимо принимать хотя бы одну… но пяти уже достаточно (для передозировки, естественно)». Пациент почему-то ожидает точный рецепт, а не нестрогое ограничение.
Не так. Вы упустили следствие. Сколько таблеток необходимо принимать, чтобы что?
Вопрос: «доктор, сколько таблеток мне необходимо принимать, ЧТОБЫ ВЫЗДОРОВЕТЬ». Ответ: «Необходимо принимать 5 таблеток, но ДОСТАТОЧНО ЛИ ЭТО БУДЕТ ЧТОБЫ ВЫЗДОРОВЕТЬ неизвестно. Возможно понадобится дополнительное обследование.»
С недавних пор сам участвую в собеседованиях в качестве интервьюера. Наверно, выделил бы пункт 4. Заметил, что если у меня есть желание пообщаться на околотехнические темы с собеседуемым, то он действительно хороший спец. Бывает даже что слишком крутой для требуемых обязанностей, о чем честно сообщается.
В том-то и дело, что люди, явно не изучавшие мат дисциплины, плохо различают =>, <= и <=>, в результате чего часто бывает неверная интерпретация некоторых вещей. Банально путаются причины со следствием.
Отсутствие преимуществ уже есть недостаток. Ну и потом, именование массива тоже может попасть под код-стайлы, у вашего array() шансов никаких против [] в этом случае.
Ну у Node.js недавно только 0.11 только было =)
Потому что для кого-то это не минус?
Ну у MySQL нет не то что решающих, а вообще никаких преимуществ. Все, что умеет MySQL, умеет и Postgre. Зато MySQL не умеет вагон того, что есть в Postgre. В пользу MySQL можно привести только чуть более мощную инфраструктуру (база знаний, вопросов, БД клиенты такие как Workbench и PHPmyAdmin).
>> Простой пример рассказа “Ваш старенький форум поддержки уже не справляется с наплывом посетителей, данные жалко, MySQL трещит по швам, дорабатывать сайт некому? «Тру» репликация PG вас спасет. Мы расскажем Вам как быстрее мигрировать”
Просто вставьте новую колонку в таблицу с 100кк записей.
Ситуация 1: если БД ругается, то пользователь создает баг-репорт, отправляет разработчику, разработчик правит, работаем дальше.
Ситуация 2: БД не ругается, пользователь думает, что все норм. Далее еще полгода работа продолжается в таком же режиме. Затем, когда надо поднять информацию, оказывается, что половины данных нет. Все получают по шапке.
— Размерность поля на производительность, кажется, не оказывает практически никакого влияния.
— Насчет INSERT IGNORE и в правду не очень понятно, почему это плохо.
Не так. Вы упустили следствие. Сколько таблеток необходимо принимать, чтобы что?
Вопрос: «доктор, сколько таблеток мне необходимо принимать, ЧТОБЫ ВЫЗДОРОВЕТЬ». Ответ: «Необходимо принимать 5 таблеток, но ДОСТАТОЧНО ЛИ ЭТО БУДЕТ ЧТОБЫ ВЫЗДОРОВЕТЬ неизвестно. Возможно понадобится дополнительное обследование.»