Если минимально субьективно про atom, то в принципе всё то же, но из коробки не получите навигацию по классам, дебагер, синхронизацию с девом и автодополнение не вполне адекватное. Всё это лечится плагинами, но может потребоваться последняя версия PHP. В принципе покрывает 90% потребностей. В гит умеет, всякие плюшки друг у друга со штормом воруют так часто, что не поймёшь кто у кого.

https://habrahabr.ru/company/devconf/blog/353682/ статью с прошлого девконфа сделал. там чел очень низкоуровнево сравнивает пострес и иннодб. и чем первый не подошел уберу :) просьба плюсануть даже если не хочется читать

Слишком сложно

ну ясное дело. у нас не уберы :)

Кому вообще нужны эти кластеризованные индексы и сборка мусора в куче, только программистам под sql

но блин. мне понравилось :)

в смысле кому??

так бд работает

Если даже ты пойдешь в убер прогромировать то там все равно вопросами бд занимаются отдельные дяди

Если даже ты пойдешь в убер прогромировать то там все равно вопросами бд занимаются отдельные дяди

ясное дело

да даже не в убере. я не касаюсь продакшена вообще никак. только иногда с рид реплики что поселекчу...

есть девопсы и админы бд...

Вот я тоже прода перестал касаться на текущей работе

Сразу так спокойно на душе стало

Сразу так спокойно на душе стало

инеговори :)

https://habrahabr.ru/company/devconf/blog/353682/ статью с прошлого девконфа сделал. там чел очень низкоуровнево сравнивает пострес и иннодб. и чем первый не подошел уберу :) просьба плюсануть даже если не хочется читать

О. Я смотрел тот доклад

Доводы меня не очень убедили, надо сказать

Доводы меня не очень убедили, надо сказать

Почему?

Почему?

Уже плохо помню.

Наверно потому что там какие то задротские детали с которыми врядли кто то сталкивается в жизни

А вот всякие баги по тихому обрезанию строк и нетранзакционному ddl мы ловим регулярно

@chebotarevp приходи и расскажи что волнует обычных разработчиков :)

Скажу так, что для типичной работки на коей я нахожусь, все эти технологические наркоманства вообще не в приоритете

У нас тут проблемы с моделированием доменной области и проработкой документации

обычных разработчиков волнуте сорт пива, блокировка телеграма и коррупция ;)

не думаю, что это формат девконфы ;)

Наверно потому что там какие то задротские детали с которыми врядли кто то сталкивается в жизни

Не. Доклад точно был интересным. Но доводы были довольно спорными. Скорее применимыми в очень определенных узких кейсах

обычных разработчиков волнуте сорт пива, блокировка телеграма и коррупция ;)

Это то да

Ещё меня волнует сраный трактор, который надо бы заводить

Кстати статья реально хорошая и полезная и нормлаьный разработчик должен знать хотя бы в общих чертах узкие места баз данных. А там хорошо они расписаны.

https://habrahabr.ru/company/devconf/blog/353682/ статью с прошлого девконфа сделал. там чел очень низкоуровнево сравнивает пострес и иннодб. и чем первый не подошел уберу :) просьба плюсануть даже если не хочется читать

я туда не пишу и мне + поставить кармы нет, статья конечно в духе убера... вообще старая же (года два вроде) и уже не помню почему я считаю ее бредом, а перечитывать нет желания, но коротко вот http://thebuild.com/presentations/uber-perconalive-2017.pdf

Доклад легендарный прежде всего потому что постгресистам дали первый публичный подсрачник, а до этого они psql считали чуть ли не идеалом и во всем превосходящим mysql

Доклад легендарный прежде всего потому что постгресистам дали первый публичный подсрачник, а до этого они psql считали чуть ли не идеалом и во всем превосходящим mysql

серьезно? от гребцов убера?))) https://news.ycombinator.com/item?id=12201353

статья убера более холиварная

и значительно больше воды

и эмоций

Ну не, даже среди pgsql комьюнити были люди которые признали эти косяки, и ее разбирали подробно все кому не лень. Там нет дыма без огня.

ну я в закладки добавил этот перевод, почитаю обязательно, но ближе к выходным, там букв много )

Ну не, даже среди pgsql комьюнити были люди которые признали эти косяки, и ее разбирали подробно все кому не лень. Там нет дыма без огня.

да косяков везде полно, но это не значит что конкретный кейс одной компании изменит рынок )))

кому лень комменты читать с харекнюса, например This later comment in the thread (https://www.postgresql.org/message-id/flat/7663dfec-e46a-401...), by Merlin Moncure, describes a set-up that most applications have, and I agree with his assessment of it: Taking a step back, from the outside, it looks like uber: *) has a very thick middleware, very thin database with respect to logic and complexity *) has a very high priority on quick and cheap (in terms of bandwidth) replication *) has decided the database needs to be interchangeable *) is not afraid to make weak or erroneous technical justifications as a basis of stack selection (the futex vs ipc argument I felt was particularly awful -- it ignored the fact we use spinlocks) The very fact that they swapped it out so easily suggests that they were not utilizing the database as they could have, and a different technical team might have come to a different result. Postgres is a very general system and rewards deep knowledge such that it can outperform even specialty systems in the hands of a capable developer . . .

да косяков везде полно, но это не значит что конкретный кейс одной компании изменит рынок )))

Вот как раз этот тезис и внедрил убер своим докладом

А до этого ходило бытовое мнение что в pgsql косяки отсутствуют ;)

http://0x1.tv/%D0%A1%D0%B8%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D1%81%D1%82%D0%BE%D1%80%D0%BE%D0%BD%D1%8B_MySQL_%D0%B4%D0%BB%D1%8F_%D0%B2%D1%8B%D1%81%D0%BE%D0%BA%D0%BE%D0%BD%D0%B0%D0%B3%D1%80%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8B%D1%85_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2_(%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D0%B9_%D0%9A%D0%BE%D0%BF%D1%8B%D1%82%D0%BE%D0%B2,_SECR-2016) вот еще интересный доклад, там внизу можно потыкать на картинки

на самом деле я не хочу вспоминать и разбираться опять, но на сколько помню было ощущение что они просто не понимают что такое постгрес и изначально использовали его как mysql (и если не ошибаюсь он на него от туда и перехали)

а косяков полно везде. исправление конкретных косяков в любом популярном продукте -это популярная тема для построения стартапов же )

на самом деле я не хочу вспоминать и разбираться опять, но на сколько помню было ощущение что они просто не понимают что такое постгрес и изначально использовали его как mysql (и если не ошибаюсь он на него от туда и перехали)

Твое утверждение ведет к необходимости им перестраивать свои процессы, модели данных, что для бизнеса может быть недопустимо и это опять же косяк pgsql

просто им иначально не нужно было с mysql переезжать на постгрес, а раз сами накосячили нефик потом такой срач разводить ))) и это не косяк -это принципиально иной подход во многом. потому странно ждать совместимости

Ну все таки база для задач бизнеса а не бизнес под возможности базы.

А

Ну все таки база для задач бизнеса а не бизнес под возможности базы.

при чем тут бизнес. Бизнес решает проблему покупателя, а база -это методология хранения. Они изначально строили модель под другие оптимизации. Очень глупо (в духе убера) было пытаться эту модель применить в другой экосистеме

Вот, что еще раз доказывает что постгрес не всеяден и под него надо строить модель эксклюзивно. То есть совет "в любом случае предпочитай постгрес мускулю" абсолюно неверен.

вообще любой разумный бизнес экслюзивно должен смотреть на свою модель данных и задачи. Всеядных баз не существует. тут вообще не особо понятно зачем уберу нужна реляционная модель. Но я в детали их процессов не вникал и возможно у них есть доводы.

чтобы джоинить наверное )

https://habrahabr.ru/company/devconf/blog/353682/ статью с прошлого девконфа сделал. там чел очень низкоуровнево сравнивает пострес и иннодб. и чем первый не подошел уберу :) просьба плюсануть даже если не хочется читать

а чем она отличается от статьи в корп блоге убера?

а чем она отличается от статьи в корп блоге убера?

думаю мало чем. но мне понравилось что тут реально много интересного из внутренностей рассказано. и проблемах с этим. довольно интересно

Подскажите пожалуйста У меня из одного php файла берётся строка и парсится в другом. Строка $row[0] = "154|Яблоко" (выдает БД) Вот два кода: 1) https://pastebin.com/p7hbmjAZ Передаст в файл действием get_subject($day,$row[0]) значение $row[0]=154|\xD0\x9F\xD0\x9B\xD0\x90\xD0\x9D\xD0\x98\xD0 2) Во втором коде $row[0] мы уже перевели в $subject. $subject = get_subject($day,$subject); - передаст файлу "Яблоко" Почему так? $day - число

Подскажите пожалуйста У меня из одного php файла берётся строка и парсится в другом. Строка $row[0] = "154|Яблоко" (выдает БД) Вот два кода: 1) https://pastebin.com/p7hbmjAZ Передаст в файл действием get_subject($day,$row[0]) значение $row[0]=154|\xD0\x9F\xD0\x9B\xD0\x90\xD0\x9D\xD0\x98\xD0 2) Во втором коде $row[0] мы уже перевели в $subject. $subject = get_subject($day,$subject); - передаст файлу "Яблоко" Почему так? $day - число

get_subject в студию)

явно дело в кодировке

явно дело в кодировке

https://pastebin.com/MfBAkzdA

Есть книги по PDO+MySQL?

get_subject в студию)

мне не понятен тот момент, что если берём не с цикла while после бд - всё ок, а если с цикла - белеберда отправляется

ERROR: S client not available

https://pastebin.com/MfBAkzdA

можно попробовать добавить mb_internal_encoding ("utf-8"); в первый файл

можно попробовать добавить mb_internal_encoding ("utf-8"); в первый файл

не помогает ( У БД настройки такие: $link->query("SET NAMES 'utf8'"); $link->query("SET CHARACTER SET 'utf8'"); $link->query("SET SESSION collation_connection = 'utf8_general_ci'");

мне не понятен тот момент, что если берём не с цикла while после бд - всё ок, а если с цикла - белеберда отправляется

а если убрать mb_internal_encoding из второго файла?

$result = $link->query("SELECT D152 FROM 19;"); while ($row = $result->fetch_array()) { if($subject=="") { $subject = get_subject($day,$row[0]); } else { $subject = "$subject\n".get_subject($day,$row[0]); } } get_subject($day,$subject); Ну вот если по этому коду смотреть - $row[0] перешлёт белеберду, а вот $subject нормальный текст Тут логика вообще мне не понятна, как так получается

: get_subject(NULL, '361|\xD0\x9B\xD0\x95\xD0\xA2\xD0\x9D\xD0\x9E-...')

Посоны

Как пересесть с 5.4 на 7.1 не используя Вазелин?

Как пересесть с 5.4 на 7.1 не используя Вазелин?

никак

читаешь http://php.net/manual/ru/migration55.php http://php.net/manual/ru/migration56.php http://php.net/manual/ru/migration70.php http://php.net/manual/ru/migration71.php в разделе "Изменения, ломающие обратную совместимость" и анализируешь свой код

Как пересесть с 5.4 на 7.1 не используя Вазелин?

если ничего сверх огромного - не трудно. вот буквально неделю назад с 4.7 вроде как на 5.6 перевел народ.

Как пересесть с 5.4 на 7.1 не используя Вазелин?

Притом если я ничего не путаю то основные изменнения между 5.* в 7.* коснулись Exteptions

если ничего сверх огромного - не трудно. вот буквально неделю назад с 4.7 вроде как на 5.6 перевел народ.

4.4.7*

Притом если я ничего не путаю то основные изменнения между 5.* в 7.* коснулись Exteptions

Не Exceptions а Error

если ничего сверх огромного - не трудно. вот буквально неделю назад с 4.7 вроде как на 5.6 перевел народ.

Омг

Работал кто то с AR вне Фраемворков Yii,Laravel ?

Работал кто то с AR вне Фраемворков Yii,Laravel ?

zend)

zend в том же числе, На чистом AR с git , без модификаций через фрамворки

ну может я и работал. это важно?

они от фреймворков никак не зависят

Да у меня вопросы по нему есть, 2й день пока не получается relations настроить

по AR? :)

Ага)

ну фреймворки тебе не помогут его настроить...

Фракмворки тут не при чем, Я просто наследую \ActiveRecord\Model, но вот настроить Связи не получается, есть у кого времечко чисто объяснить что делаю не так или примерчит простой показать

я так подозреваю что ты имеешь ввиду Yii активрекорд?

Нет AR взятый с этого репозитория, https://github.com/jpfuentes2/php-activerecord Фрамворк не используется никакой популярный

тебе не кажется что именно с этого и надо было начинать?

я с ним не работал

Жаль, ладно буду дальше копаться в исходниках)