Разумеется, так и будет. Чем сильнее индексирована таблица, тем дольше будут происходить опрерации вставки. Следует оценить, нужны ли все индексы? Какие запросы выборки проводятся? И часто ли вообще происходят выборки? Как часто происходст вставки?
Если и выборки и вставки критичны и оба процесса происходят часто, вероятно, имеет смысл создать репликацию по типу OLAP-OLTP. Но тогда, разумеется, возникнет оверхед при репликации.
Гм, предполагаю, что с точки зрения быстродействия в общем случае в примере первого сообщения всё будет очень - печально.
Например, разыменование вложенных массивов продемонстрировано здесь, параграф "Using the =&-ref-operator" и далее. Точнее сказать нельзя - недостаточно кода. Но, уверен, после просмотра опкодов для ZVM всё встанет на свои места.
Кроме того, если нужно будет использовать код где-нибудь ещё, его нужно будет копировать. А если в одном из скопированных мест забыть изменить функционал при, например, расширении возможностей приложения, то будет очень сложно найти, почему всё работает не так, как планировалось.
Такой подход - как компиляция анти-паттернов. Всё перечислить вряд ли представляется возможным, да и незачем. Возможно, автору темы следует изучить основы computer science (не знаю хорошего перевода, все не нравятся), почитать о базовых структурах данных, изучить используемые концепции, подходы. После - уже продвигаться дальше и с имеющейся базой подходить к ООП и ему подобным вещам.
Если единого формата нет - то только через приложение. В PHP это strtotime или DateTime API. Можно написать хранимцю процедуру, но никакой разницы с приложением по сути не будет (за исключением того, что придётся вручную описывать распознавание даты)
Если же какой-либо единый формат всё же есть (пусть и не корректный с точки зрения типов хранения даты) - то STR_TO_DATE
В случае вызова по дереву вышестоящих родительских классов - разницы не будет в силу переноса контекста объекта (о чем была дана выше ссылка). Но общий случай состоит в том, что строковое имя может указывать не на один из классов-предков.
Всё зависит от используемой СУБД и решаемых задач. Если речь о MySQL - там stored procedures плохи по самому своему устройству, почти всегда стоит делегировать это приложению. Но если речь идёт о, например, Oracle - то нередко в таких приложениях значительная часть бизнес-логики поручается СУБД и весьма успешно. Приложения не только для веб бывают.