Максим, честно говоря, представить себе полную структуру по тексту вряд ли кто-то сможет, или нужно долго и усиленно вникать. Все-таки обычно это делают схемой с указанием связей.
А что с ключами? Я так догадываюсь, что у user натуральный ключ email, а у friend составной ключ?
Максим, все таки модули это относительно независимые, самостоятельные единицы, я бы не стал выделять что-либо в модуль без нужды. К примеру, api для проекта просто просится в отдельный модуль, а вот Пользователь, Организация, просто взаимозависимые сущности, имхо.
d-stream, я так понимаю съезжаете с темы? Тогда, я писал что нужен эксепшен, не забывайте.
"в которой указать что конкретно должно быть в ситуациях с любыми другими значениями.", так что указать? Я понимаю ваше затруднение, т.к. автор ничего не указал, но именно поэтому и спрашиваю.
И прочитайте ещё раз ваш пример, о какой портабельности и разных диалектах после этого вы говорите?
А если на понятном вам языке, то я действительно сожалею, что вас так обошли с должностью. Но в вашем возрасте уже пора делать выводы и корректировать свое поведение, может тогда к вам будут прислушиваться, а если не желаете, то вам задачка: пишите сюда, здесь вас не обидят.
ps читайте между строк. Завтра утром проверю :-)
d-stream, "просто достаточно прочитать между строк"? Это ж где вы так работаете? Клиент хочет перевести деньги на счёт, но счёт не указал, ну ничего переведем его деньги дяде Вове, скорее всего он его имел ввиду. Получается вы так работаете? Проработка исключений и ошибок не имеет ничего общего с придумыванием своего поведения. Раз вам так зачесалось, давайте подробнее, что не обрабатывает case? Отсутствие данных? Расскажите, пожалуйста, кому вы переведёте деньги, если клиент этого не указал в переводе - прочитайте между строк.
И укажите, пожалуйста, вашу организацию, таких "специалистов" нужно знать, и обходить стороной. А вам следует задуматься, почему в вашей конторе люди не остаются больше чем на месяц.
d-stream, вы уже все перемешали в кучу, у нас 2 вопроса:
1. Как бы вы не сортировали вне задания, это в любом случае неправильное поведение. Неважно куда вы поместите null, если по условию их не должно быть.
2. С каких пор использование всех возможностей СУБД стало дурным стилем, а если речь про додумывание поведения вне задания, то п.1.
d-stream, дело не в телепатии, какой бы из неправильных вариантов сортировки вы не выбрали, он все равно будет неправильным, т.к. при составлении запроса потеряли данные.
Тоже самое с полом, если в пришедших данных пол не указан, то правильный не нужно угадывать, по хорошему здесь должен был быть эксепшен.
О каком проекте мы сейчас говорим? Правильно ни о каком, так какие варианты портабельность нам следует соблюдать? Правильно, нет их на данном этапе. Так о каких ямах идёт речь?
d-stream, может быть, но в задаче все равно нет этого else, так что если туда что-то и попадет, то уже все пошло не так, поэтому не важно куда, результат уже не верен.
Да и портабельность в немаленьких проектах мало осуществима.
Виталий Ефимов, полторы недели это очень мало, вообще не парьтесь, то что ваши коллеги сыпят терминами, которых вы не понимаете, то что не можете сделать элементарные вещи. Даже не джуниор сталкивается с такими вещами, т.к. везде своя специфика (зачастую свои ужасные костыли). Руководитель с вами вообще не общается или хотя бы направил к старшему коллеге, который вас курирует?
Если вас не вводили постепенно, не сформировали базу, то не удивительно, что вы пребываете в таком состоянии. Я бы в таком случае, систематизировал что нужно освоить сам (раз руководство не делает), и все равно будет сложно, т.к. не знаете подводных камней.
Ещё раз, вы джуниор, ваша задача учиться и перенимать опыт коллег. Если не спрашиваете у коллег одно и тоже, значит процесс обучения идёт. Не забывайте и о том, что человек принимающий решение по результатам испытательного срока тоже должен быть в курсе вашего прогресса. Проанализируйте что вы уже изучили, если ничего то, пройдитесь ещё раз.
Релокация это все равно стресс, новая работа тоже стресс, но не стоит загоняться без явной причины, знаю людей, которых выгоняли, ничего, работают на лучших местах. Очень важно поддерживать психологическое состояние, высыпайтесь, гуляйте, благо в Москве полно парков и красивых мест.
В любом случае, в Москве предложений гораздо больше, чем в любом другом городе. Знаю человека который менял работу каждые 1-4 месяцев, пока не нашел по душе.
Посмотрел почти до конца ролик в примере. С одной стороны он говорит об элементарных вещах, которые действительно должны быть. И действительно часто делают в коде то, что в запросе решается в разы проще и быстрее. Хотя мне все равно кажется, что нечисловой натуральный первичный ключ хуже решение, чем суррогатный числовой. С другой стороны, он явно не понимает зачем нужны ORM. Ведь ORM мы применяем не для того, что они лучше нас сформируют структуру БД, а для ускорения разработки. Понятно, когда у нас высоконагруженная система, то странно запускать ее на MySQL с ORM. А жаловаться что MySQL не делает того, что по документации и не должен - странно.
hostadmin, не обязательно клон, вставку ведь можно любую сделать. Если клон, то можно сделать то же самое партиционированием, но нужно будет везде таскать where или делить на таблицу и вьюху. Нет, под рукой кода нет, но как я написал там все просто, один инсерт с условием.
Из хороших применений триггеров я знаю: инкрементация первичного ключа при вставке и перемещение данных в историю при удалении. Буду благодарен, если поделитесь своим мнением.
А вот когда мы делаем вставку во вьюху, триггер ее перехватывает и запускает процедуру делающую ещё дюжину апдейтов и инсертов, а по ним запускаются ещё триггеры, ещё вставки и обновления. Тогда хочется поубивать кого-нибудь. Понятно что везде должен быть здравый смысл, но триггеры та вещь, с которой нужно быть очень осторожным.
Имхо, когда пишешь что-то без фреймворка, то начинаешь писать свой фреймворк, если же такого не наблюдается, значит у тебя проблемы с повторным использованием кода. Т.к. в большинстве случаев все равно нужен роутинг, работа с БД, авторизация и прочее. Т.е. либо пишешь велосипед, либо собираешь по частям из готового, по-сути тратя время, когда за тебя уже все сделали, но "для души", а вернее для самообразования очень полезно, чтобы понимать почему в фреймворках сделано именно так, а не иначе.
Кстати, очень часто коммерческое ПО в силу исторических причин написано без фреймворков, или задействуя фреймворк процентов на 30, или используя очень простой фреймворк, такой, что его по-сути и нет.