Ну, если в проекте большое количество таблиц с огромным количеством записей, разгица между мускулем и постгрес будет очень хорошо заметнаТрындеж, основанный ни на чем. Обе базы сопоставимы по производительности, сказки про то что постгрес как-то волшебно ускоряет большие объемы данных - городская легенда. Более того, при сопоставимой нагрузке мускуль будет жрать меньше памяти и проца.
И PostgreSQL, и MySQL известны как одни из самых быстрых решений СУБД на рынке. Однако в этой категории нет явного победителя. Вы можете довольно легко найти бенчмарки, которые рекомендуют одну базу данных на основе конфигурации, теста и оборудования. Одна может иметь преимущество в параллелизме, в то время как другая может лучше справляться на одноядерной машине с небольшим объемом памяти.источник
Вдруг человек хотел горизонтальное масштабирование подключитьТак мускуль очень хорошо масштабируется в ширину. Есть небольшая разница в работе шардинга мускуля и постгреса, но однозначно сказать что подходит в конкретном случае сложно. Тем более нет смысла гадать без каких-то объективных данных.
Господа, пожалуйста, покажите хоть один сайт, где есть форма из которой вынесли submit куда-то далеко.В последний раз видел такую форму в админке booking.com, лет этак 8 назад. Связанно это с тем что формы там сложные, динамически добавляются и удаляются десятки полей, а кнопки вынесены в отдельный блок, дабы во всей этой свистопляске не участвовать. Подозреваю что сегодня все это переписано на какой-нибудь вью или ангулар, но то что это используемая (хоть и редко) фича - факт.
Так бывает. И это совершенно не является проблемой, если кнопки указать атрибут formЭто делают в случаях когда функционал или разметка не позволяет расположить кнопку внутри формы, то есть обходной механизм для поддержки стандартного функционирования. Здесь же это сделано больше из тыканья пальцем в различные участки небосвода, а не из понимания работы формы.
То есть все способы валидации видят это поле как заполенное и имеющее значение 0000-00-00"Все" это какие? Валидация через указание require базовый функционал формы, но не единственно возможный. Если вы прикручиваете к элементам дополнительные функциональные фичи, вам придется что-то делать самому. У вас есть объект формы, любое поле в которой вы можете получить и обработать, что мешает проверить конкретно данное поле на наличие определенной строки?
а то я изначально думал, что нужно дойти до 5 kata хотя бы и выучить алгоритмы для продолженияАлгоритмы на пустом месте вы забудете буквально через неделю, алгоритм примененный в живом проекте запомнится если не навсегда, то на достаточно большое время, чтобы считаться заученным.
(почему-то иногда бумага по умолчанию сама по себе переключается на универсальный лоток (который для конвертов), а там ничего нет, естественно)Так происходит когда размер печатаемого документа не соответствует бумаге в основном лотке. Еще бывает софт по умолчанию сбрасывает номер лотка, если не получает ответ от принтера за установленный таймаут...
типа с использованием convert castлюбой каст это костыль, сильно снижающий производительность. Ты же понимаешь, что все значения в таблице для кастовых операций нужно привести в один вид, то есть каст будет на все данные сразу, иначе сравнивать преобразованные данные с непреобразованными не получится. Как разовый запрос с целью что-то быстренько под себя получить конечно можно, но на крупном проекте с миллионами записей будет очень больно...
там далеко даже нет таких выборокТам нет таких выборок сейчас, не факт что завтра тебе не понадобится выбрать какие-то статистические данные по сегментам, даже тупо разбить на календарные месяцы будет уже неслабым геморроем...
SELECT DATEDIFF(date, CURDATE()) days_until
FROM dates_table
WHERE date >= CURDATE()
AND DAY(date) = 13
AND WEEKDAY(date) = 4
ORDER BY date
LIMIT 1;