> По-моему, очень красивый пример.
По-моему это задача для совсем совсем джуниора. Неясно что тут проверяется, знает ли человек что такое условные переходы?
Этакая задача на уровне 7 класса средней школы.
На нормальных собеседованиях обычно не заставляют за минуту придумать сложный алгоритм и написать правильно работающую реализацию.
Обычно смотрят на ход мыслей, на то что человек вообще способен думать.
Т.е. в большинстве случаев обычно достаточно «ну наверное я бы начал думать вон в ту сторону и попробовал бы вот так»
А вот люди которые не знают даже примерно, как работают базовые вещи, ну например, сортировка — это как бы не программисты.
>Это просто пример таблиц. Так в какое DAO сувать запрос с join, в accounts или logs?
А ну да, еще можно какой-нибудь хитрый mapper намутить, но я это дело не люблю.
Оно может показаться, что так потом проще понять кто с кем связан, но по-моему проще стандартно вынести названия таблиц в константы DAO а потом тупо поиском по ним в любой момент понять кто куда обращается.
Большие проблемы обычно вызывает не понимание кто с кем связан, а сама связанность.
>В целом inner join очень быстро работает.
Дело не в скорости.
Во первых самое простое масштабирование разнести таблицы по разным серверам.
Далее можно заменить конкретный источник на другой тип базы данных, либо на что-то еще, на демон например.
>При любом намеке на highload скорее всего и от реляционных БД придется отказаться.
Это не так
>Это просто пример таблиц. Так в какое DAO сувать запрос с join, в accounts или logs?
Зачем вообще так необходим запрос с Join?
Вообще логику можно учесть, вы выводите логи с указанием пользователя или логи пользователя.
Впрочем как по мне — пофигу, одинаково фигово
Повторюсь :) Если вам нужен зачем-то join то делайте join.
Как бы сделал я — отдельные DAO accounts, logs. Склеивание на уровне PHP.
Почему так — App серверов можно поставить сколько угодно, простое горизонтальное масштабирование, в отличие от источника данных.
Далее — логи, особенно сырые хранить в базе данных, возможно, очень быстро расхочется, тут как раз появляется один из главных плюсов DAO — берем и переносим логи куда угодно, переписыв всего один класс.
Вообще запросы с join, делать при любом намеке на хайлоад не стоит, это может вызвать очень большие проблемы в будущем.
Если зачем-то очень надо таки сделать join — ну пишем запрос тупо в DAO accounts, в практике я такое часто встречал, хоть и не одобряю.
Все просто — если нужен запрос с JOIN делаем запрос с JOIN :)
Если же речь идет о выборке связанных списков из разных таблиц, то в зависимости от ситуации.
Не могу судить как вы, на сколько «товарисч» понимает разницу по этому его сообщению, но «товарисч» явно знает толк в зарабатывании денег. Речь идет о том, что для абсолютного большинства бизнес задач есть готовые или почти готовые программные решения. Но обычно рпограммисту лень/не интересно разбираться и он мутит велосипед.
У нас прогеров бывает такое, когда приобретаем некоторый, уже возможно значимый, опыт — появляется звездная болезнь.
С опытом это проходит.
>>4.1. Я НЕ ХОЛЯВЩИК, Я – ПАРТНЕР. И мы с тобой В ОДНОЙ ЛОДКЕ.
>>4.1.1. Ты рискуешь своими деньгами.
>>4.1.2. А я — своей репутацией.
Сколько эмоций и гордости, так если есть репутация — то и слушать будут и советоваться будут и, возможно, нанимать не как работника, а как партнера.
А если не партнер — то после всех подобных воплей адекватный владелец бизнеса, скорее всего, пошлет подальше.
Вообще вся статья выглядит как выплеск жуткой обиды, как попытка доказать самому себе что-то.
А чем мы прогеры так уникальны? Чем наша профессия настолько божественно отличается от других?
Отличие так то на другом уровне — ты либо очень сильный профи и тебя берут в долю и слушают, либо ты кричишь и обижаешься.
Zx spectrum, бейсик, хотя слово «прогал» по отношению этому звучит, наверное, слишком гордо :D
На самом деле мне почему-то казалось, что PHP появился где-то в 99 году.
А в то время да, Pascal, Asm, Delphi.
В защиту автора — полезная инфа все-таки есть :D
Oracle дорого и непонятно, noSQL непонятно и страшно, mySql рулит.
Что характерно про postgresql ни слова.
>>А это топик о том, что даже в 2015 году можно не стесняться и использовать простые способы для достижения >>результатов в бизнесе.
Я не имел ввиду, что mysql не очень. Если его использовать в таком плане, отличий от других noSQL критических не будет. Все все равно будет утыкаться в скорость накопителей. Вопрос то в горизонтальном масштабировании, шардинге, как организовали, какие конкретные проблемы возникали, как поиск организовали. вот это интересно.
>>Допустим на складе поставщика за последние 5 минут изменилось наличие для 10 позиций. Мы считаем, что update >>where… это самый правильный способ обновить данные. У вас есть вариант более лучший?
Ниже уже написали про infile, insert on dublicate. Вообще трудно предложить хороший вариант, не зная деталей.
>>Возможно люди на хабре ждут каких-то новых технологий, я же писал о реальных результатах.
Мне всегда казалось, что на хабре ждут рассказа не о том как что-то сделали, а о том как это сделали :)
>>Количество операций UPDATE примерно в 10 раз больше, чем количество операций SELECT.
Как-то совсем непонятно. У вас прайсы которые никому не интересно читать но зачем-то интересно писать?
Или вы там на полном серьезе делаете на каждый чих update where id =.?
На счет полезности информации — создать топик для откровений «мы смогли только innoDB как noSql заюзать» в 2015 году это сильно.
По своему опыту скажу — электронные не выход, зависимость остается ровно такая же, если даже сильнее не становится.
Все-таки с электронной намного проще употребить больше никотина.
В какой-то момент, когда электронных не будет то снова появятся обычные.
При этом такие переходы для организма еще один дополнительный стресс.
Электронные сигареты, таблетки, пластыри — все это бред и очередное вытягивание денег на плохих привычках.
Если бросать то только сразу.
То что обычные сигареты это совсем фигово и так уже все знают.
А вот то что электронные далеко не безопасны задумываются не многие.
Продаже обычных сигарет упали — начали делать электронные, еще и рекламируются прикрываясь заботой что «они безвредные, в отличие от обычных».
В результате теперь появляется куча людей, которые обычные и не курили никогда, зато курят электронные.
Так что нормально такое исследование, если бы тут еще и обычные приплели, вред электронных на их фоне был бы прям рекламой.
По-моему это задача для совсем совсем джуниора. Неясно что тут проверяется, знает ли человек что такое условные переходы?
Этакая задача на уровне 7 класса средней школы.
Обычно смотрят на ход мыслей, на то что человек вообще способен думать.
Т.е. в большинстве случаев обычно достаточно «ну наверное я бы начал думать вон в ту сторону и попробовал бы вот так»
А вот люди которые не знают даже примерно, как работают базовые вещи, ну например, сортировка — это как бы не программисты.
А ну да, еще можно какой-нибудь хитрый mapper намутить, но я это дело не люблю.
Оно может показаться, что так потом проще понять кто с кем связан, но по-моему проще стандартно вынести названия таблиц в константы DAO а потом тупо поиском по ним в любой момент понять кто куда обращается.
Большие проблемы обычно вызывает не понимание кто с кем связан, а сама связанность.
Дело не в скорости.
Во первых самое простое масштабирование разнести таблицы по разным серверам.
Далее можно заменить конкретный источник на другой тип базы данных, либо на что-то еще, на демон например.
>При любом намеке на highload скорее всего и от реляционных БД придется отказаться.
Это не так
>Это просто пример таблиц. Так в какое DAO сувать запрос с join, в accounts или logs?
Зачем вообще так необходим запрос с Join?
Вообще логику можно учесть, вы выводите логи с указанием пользователя или логи пользователя.
Впрочем как по мне — пофигу, одинаково фигово
Как бы сделал я — отдельные DAO accounts, logs. Склеивание на уровне PHP.
Почему так — App серверов можно поставить сколько угодно, простое горизонтальное масштабирование, в отличие от источника данных.
Далее — логи, особенно сырые хранить в базе данных, возможно, очень быстро расхочется, тут как раз появляется один из главных плюсов DAO — берем и переносим логи куда угодно, переписыв всего один класс.
Вообще запросы с join, делать при любом намеке на хайлоад не стоит, это может вызвать очень большие проблемы в будущем.
Если зачем-то очень надо таки сделать join — ну пишем запрос тупо в DAO accounts, в практике я такое часто встречал, хоть и не одобряю.
Если же речь идет о выборке связанных списков из разных таблиц, то в зависимости от ситуации.
С опытом это проходит.
>>4.1. Я НЕ ХОЛЯВЩИК, Я – ПАРТНЕР. И мы с тобой В ОДНОЙ ЛОДКЕ.
>>4.1.1. Ты рискуешь своими деньгами.
>>4.1.2. А я — своей репутацией.
Сколько эмоций и гордости, так если есть репутация — то и слушать будут и советоваться будут и, возможно, нанимать не как работника, а как партнера.
А если не партнер — то после всех подобных воплей адекватный владелец бизнеса, скорее всего, пошлет подальше.
Вообще вся статья выглядит как выплеск жуткой обиды, как попытка доказать самому себе что-то.
А чем мы прогеры так уникальны? Чем наша профессия настолько божественно отличается от других?
Отличие так то на другом уровне — ты либо очень сильный профи и тебя берут в долю и слушают, либо ты кричишь и обижаешься.
Скорее всего оно тут про это.
На самом деле мне почему-то казалось, что PHP появился где-то в 99 году.
А в то время да, Pascal, Asm, Delphi.
Oracle дорого и непонятно, noSQL непонятно и страшно, mySql рулит.
Что характерно про postgresql ни слова.
Я не имел ввиду, что mysql не очень. Если его использовать в таком плане, отличий от других noSQL критических не будет. Все все равно будет утыкаться в скорость накопителей. Вопрос то в горизонтальном масштабировании, шардинге, как организовали, какие конкретные проблемы возникали, как поиск организовали. вот это интересно.
>>Допустим на складе поставщика за последние 5 минут изменилось наличие для 10 позиций. Мы считаем, что update >>where… это самый правильный способ обновить данные. У вас есть вариант более лучший?
Ниже уже написали про infile, insert on dublicate. Вообще трудно предложить хороший вариант, не зная деталей.
>>Возможно люди на хабре ждут каких-то новых технологий, я же писал о реальных результатах.
Мне всегда казалось, что на хабре ждут рассказа не о том как что-то сделали, а о том как это сделали :)
Как-то совсем непонятно. У вас прайсы которые никому не интересно читать но зачем-то интересно писать?
Или вы там на полном серьезе делаете на каждый чих update where id =.?
На счет полезности информации — создать топик для откровений «мы смогли только innoDB как noSql заюзать» в 2015 году это сильно.
По своему опыту скажу — электронные не выход, зависимость остается ровно такая же, если даже сильнее не становится.
Все-таки с электронной намного проще употребить больше никотина.
В какой-то момент, когда электронных не будет то снова появятся обычные.
При этом такие переходы для организма еще один дополнительный стресс.
Электронные сигареты, таблетки, пластыри — все это бред и очередное вытягивание денег на плохих привычках.
Если бросать то только сразу.
А вот то что электронные далеко не безопасны задумываются не многие.
Продаже обычных сигарет упали — начали делать электронные, еще и рекламируются прикрываясь заботой что «они безвредные, в отличие от обычных».
В результате теперь появляется куча людей, которые обычные и не курили никогда, зато курят электронные.
Так что нормально такое исследование, если бы тут еще и обычные приплели, вред электронных на их фоне был бы прям рекламой.