Не понимаю, за что минусуют, но я категорически плюсую. Делать вместо многомерныйх не структурированных массивов чёткие структурированные объекты — это признак хорошего тона, особенно, если в твоём коде будут разбираться другие программисты вооруженные топорами и бензопилами. Yaml и XML не спасут, если ты не помнишь названия переменных/атрибутов наизусть и иногда опечатываешся.
Это то же самое, что создавать константы для ключевых слов:
<?
class Image {
const RESIZE_METHOD_RESIZE = 'resize';
const RESIZE_METHOD_CROP = 'crop';
const RESIZE_METHOD_CROP_TOP = 'cropTop';
const RESIZE_METHOD_CROP_WITHOUT_CROPPING = 'cropWithoutCropping';
const RESIZE_METHOD_SOMTHING = 'somthing';
const RESIZE_METHOD_ETC = 'etc';
// Эти константы не нужны для какой-то логики,
// но они нужны для автокомплита и что бы не опечататься.
}
?>
Мне гораздо больше запомнилось как скалакси дважды за год угробил дисковую систему без возможности восстановления данных. Пришлось восстанавливаться из бекапов, и переезжать в хецнер.
Если вы собираетесь модифицировать классы (добавлять новые методы или модифицировать геттеры/сетторы), то перегенерацию кода лучше не использовать. А если вы не собираетесь модифицировать классы, то в чём профит? Только в автодополнении?
Я не имею ввиду что это сложно. Я имею ввиду что это хрупко. Если не мне а другому программисту потребуется добавить новое поле, он сделает ALTER TABLE, но вспомнит ли он про новое поле в User?
Сдаётся мне, что если у вас есть не самый большой проект состоящий из 50 таблиц, в каждой из которых, в среднем, по 10 полей (всего 500 полей), то поддерживать в актуальном состоянии 100 классов и 1000 методов (сеттеры+геттеры) будет не то что бы накладно, а очень хрупко. Особенно если над проектом работаете не только Вы один.
Это конечно очень и очень круто и я стремлюсь к этому, но уж очень напрягает плодить отдельный класс для каждого массива. Всё это порождает другие сложности. Я бы назвал их «бюрократическими».
//Эта конструкция говорит парсеру, что будет возвращен массив, состоящий из объектов этого класса
И если уж говорить о совсем строгой типизации, то здесь нужно делать коллекцию. Таким образом, для таблицы `users`, потребуется создать минимум два класса User + UsersCollection. Ну и ещё в класс User добавить геттеры+сеттеры для всех 22 полей. А при добавлении нового поля в таблицу, нужно не забыть добавить новое поле+геттеры+сеттеры в класс User. Это напоминает бюрократические походы в 100500 энстанций, вместо того что бы просто сделать один ALTER TABLE.
Посмотрел на повёрнутый на 45 градусов лабиринт и первая же мысль: «Здесь есть несущие колонны, но большинство стен можно снести. Получился бы не плохой оупен-спейс».
2) Транзакция№2 пытается получить блокировку типа X и… начинает ждать когда Транзакция№1 освободит блокировку S
3) Транзакция№1 пытается получить блокировку типа X и… начинает ждать когда Транзакция№2 получит блокировку типа X и освободит её
Т2 ещё не получила блокировку, по этому, можно легко дать блокировку типа Х транзакции№1.
Вообще то, я как раз говорил про логичный способ, называя его «способ, который для всех очевиден»: на третьем шаге дать первой транзакции доступ. Зачем выдавать ошибку там где ситуацию можно безошибочно разрулить?
Я не понимаю, если MySQL может задетектить сложившуюся патовую ситуацию, то почему он не может разрулить её способом, который для всех очевиден? Какие в этом способе подводные камни и будут ли они больше, чем существующий dead lock?
А причём тут вообще Михолков? Я заплатил исполнителю некоторую сумму и могу слушать эту песню сколько захочу и где захочу. Почему какой-то левый чел по имени Михолков должен получать от этого доход? Какое он имеет отношение?
Это то же самое, что создавать константы для ключевых слов:
Всё понятно…
Сдаётся мне, что если у вас есть не самый большой проект состоящий из 50 таблиц, в каждой из которых, в среднем, по 10 полей (всего 500 полей), то поддерживать в актуальном состоянии 100 классов и 1000 методов (сеттеры+геттеры) будет не то что бы накладно, а очень хрупко. Особенно если над проектом работаете не только Вы один.
И если уж говорить о совсем строгой типизации, то здесь нужно делать коллекцию. Таким образом, для таблицы `users`, потребуется создать минимум два класса User + UsersCollection. Ну и ещё в класс User добавить геттеры+сеттеры для всех 22 полей. А при добавлении нового поля в таблицу, нужно не забыть добавить новое поле+геттеры+сеттеры в класс User. Это напоминает бюрократические походы в 100500 энстанций, вместо того что бы просто сделать один ALTER TABLE.
Т2 ещё не получила блокировку, по этому, можно легко дать блокировку типа Х транзакции№1.
www.slideshare.net/billkarwin/sql-antipatterns-strike-back (см. 77 слайд, а лучше с 48, а ещё лучше с самого начала и до конца)
Не надо перевирать мои слова. Я предложил всего лишь 3 файла: