каждому свое. мне порой вообще тяжело следить за топиками.

«стрессоустойчивость» - нужно вычеркнуть из резюме

Всем привет Если делать composer-зависимости, их стоит заносить в гитигнор?

Всем привет Если делать composer-зависимости, их стоит заносить в гитигнор?

да

Всем привет Если делать composer-зависимости, их стоит заносить в гитигнор?

делать или ставить?)

Как там говорится? "Это интернет, тут и нахуй могут послать")

я плачу за интернет чтобы меня тут посылали?(9

делать или ставить?)

ну что ты определился с проектом, где без орм никак? как он выглядит?

ну что ты определился с проектом, где без орм никак? как он выглядит?

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

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

или создает

опять же - у меня мысль была показать как связи можно убрать)

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

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

Я правильно понимаю что можно взять постгрес с его jsonb и получить где нужно реляционную базу, а где не нужны нормализованные данные использовать jsonb и жить прекрасно? В том плане, что имеет ли сейчас использовать отдельно именно nosql базы типо монги?

в целом, понимаешь верно. что касается второй части, надо смотреть что именно от носкл надо

Честно говоря пока не очень понимаю где нужны ненормализованные данные. На ум приходят какие нибудь канбан доски возможно удобно будет хранить, а так не знаю, видимо mysql головного мозга у меня

Честно говоря пока не очень понимаю где нужны ненормализованные данные. На ум приходят какие нибудь канбан доски возможно удобно будет хранить, а так не знаю, видимо mysql головного мозга у меня

иногда прибегают к денормализации, потому что так быстрее

иногда прибегают к денормализации, потому что так быстрее

Например?

Чтобы джоины не делать?

Например?

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

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

нужно обладать максимальной информацией о проекте

векторе его развития и тд

Т.е. нету определенного класса задач?

все меняется и задача разработчика, иметь возможность быстро прибрать пиздец, обычно берут то что лучше всего знают тебе же никто не помешает после mvp раскидать что то по nosql и тд

Ну да, в целом понятно. Можно тогда брать постгрес и норм будет)

Спасибо

Я правильно понимаю что можно взять постгрес с его jsonb и получить где нужно реляционную базу, а где не нужны нормализованные данные использовать jsonb и жить прекрасно? В том плане, что имеет ли сейчас использовать отдельно именно nosql базы типо монги?

монга это уже больше не про реляционное vs документное (опять же потому что постгрессы не чисто реляционная база изначально и в целом с их jsonb можно жить припеваючи очень и очень хорошо практически на любом проекте). Монга это больше про ACID vs BASE

Как base загуглить?

А, нашел, спасибо. Пойду почитаю

типа basik availability, soft state, eventual consistency. Короч там где данные в одну базу не помещаются

помимо монги есть и другие варианты, и там все сильно упирается с тем что ты будешь с данными делать

но поскольку у 90% проектов база данных прям вся в оперативке поместиться может, то как бы нет особо смысла загоняться и можно взять универсальный вариант который будет хорошо работать. Ну и есть же еще микросервисы (где ты берешь эти самые данные которые в одну базу не помещаются и делаешь просто... много баз данных, правда тогда всеравно eventual consistency скорее всего придется применять ибо полностью независимо сложна)

ну а если ты хипстер достаточно можно попробовать какие-то совсем уж экзотичные штуки типа OrientDB или ArangoDB.

Спасибо, будем изучать вопрос

Спасибо, будем изучать вопрос

представь себе документ (например, накладную на отгрузку товара). у него есть стороны (контрагенты). если смотреть с точки зрения россии, то их 3: юр лицо, иностранная компания, ип. Каждый из типов подразумевает свой набор данных. у товаров в накладной тоже зоопарк свойств, нет общего шаблона. а теперь попробуй в мыслях накидать реляционную схему, что бы впихнуть невпихуемое. Безусловно, у тебя получится. Но какой ценой?)

А есть вообще крупные проекты, которые без рсубд работают?

а есть крупные проекты которые на рсубд работают?

А есть вообще крупные проекты, которые без рсубд работают?

у крупных проектов обычно не одна база данных

В том-то и дело, что nosql появляется как результат эволюции проекта. Обратные примеры, когда развитие только на nosql упирается в техническую невозможность роста, встречаются часто

В том-то и дело, что nosql появляется как результат эволюции проекта. Обратные примеры, когда развитие только на nosql упирается в техническую невозможность роста, встречаются часто

да, особенно когда этим занимаются разработчики привыкшие к реляционным базам данных (помню как сам на это напоролся когда впервые делали проект на mongodb))

ну то есть, я бы не сказал что прям "упирается в техническую невозможность" - это больше про реляционные базы скорее. Просто с nosql опять же вопросы консистентности перекладываются целиком на тебя. Ну и в целом для большинства задач это не нужно. Кроме того - тот же posgresql это не чисто реляционная база данных (ORDBMS)

а проекты где ты упираешься в нюансы реализации хранения данных - это все же больше редкость. Хотя конечно знать сильные/слабые стороны своих инструментов стоит. Вот я например до сих пор не знаю почему люди выбирают mysql вместо postgresql (особенно сейчас, когда самый большой минус постгреса - отсутствие логической репликации и партицирования толкового - уже пофикшены). Да, есть куча нюансов (особенно в том как данные хранятся на диске), но в целом для 99.99% проектов это неважно

p.s. если кто-то может мне рассказать хотя бы в контексте 1% проектов почему mysql в чем-то лучше постгри - буду признателен. Аргумент "потому что я знаю мускуль" не принимаю

p.s. если кто-то может мне рассказать хотя бы в контексте 1% проектов почему mysql в чем-то лучше постгри - буду признателен. Аргумент "потому что я знаю мускуль" не принимаю

потому, что мускуль был на проекте, когда я его получил

а выгода от перехода слишком низкая

ну это все понятно, я больше в контексте новых проектов. Ну мол я прекрасно понимаю что мускуль популярен не по объективным причинам а потому что он был популярен

ну то есть может быть 10 лет назад разница была значительной (скажем из бесплатных только мускуль умел достаточно вещей)

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

1. На больших проектах можно забыть за джоины совсем, т.к они уронят базу в два счета 2. Большие проекты шардированы и тут в консистентность ключей не все базы умеют 3. На больших проектах у тебя будет несколько сервисов, и между ними джоины ты тоже не сделаешь

и в добавок, та же монга умеет кое-как делать джоины, ты в ней будешь хранить четкую схему и наверняка валидацию схемы еще прикрутишь мускули и тому подобные умеют у себя уже хранить json во фри виде и делать еще выборки по нему так что разницы нынче не так уж и много

мускуль научился в json?

а проекты где ты упираешься в нюансы реализации хранения данных - это все же больше редкость. Хотя конечно знать сильные/слабые стороны своих инструментов стоит. Вот я например до сих пор не знаю почему люди выбирают mysql вместо postgresql (особенно сейчас, когда самый большой минус постгреса - отсутствие логической репликации и партицирования толкового - уже пофикшены). Да, есть куча нюансов (особенно в том как данные хранятся на диске), но в целом для 99.99% проектов это неважно

страх изменений сильнее профитов прогресса. Во всяком случае так, судя по всему, воспринимают действительность много людей, которые принимают решение pgsql/mysql. Обычно на таких людях лежит большая ответственность, а старый инструмент они уже изучили на практике и более менее знают что от него ожидать. В новый же инструмент нужно инвестировать время и силы - далеко не каждый на это пойдёт. К тому же может быть неясно в чём профит (а может его и нету особо для многих проектов).

мускуль научился в json?

если ты про индексы, то нет, но решается индексом по выражению (ака генерированные колонки)

мускуль научился в json?

с версии 5.7 вроде как, и вполне неплохо. Только индексы не умеет

страх изменений сильнее профитов прогресса. Во всяком случае так, судя по всему, воспринимают действительность много людей, которые принимают решение pgsql/mysql. Обычно на таких людях лежит большая ответственность, а старый инструмент они уже изучили на практике и более менее знают что от него ожидать. В новый же инструмент нужно инвестировать время и силы - далеко не каждый на это пойдёт. К тому же может быть неясно в чём профит (а может его и нету особо для многих проектов).

кто ты и куда делся кнопкодав?)

если ты про индексы, то нет, но решается индексом по выражению (ака генерированные колонки)

мускуль не умеет индекс по выражению же

ну мол мне казалось что колонки надо руками генерить

если ты про индексы, то нет, но решается индексом по выражению (ака генерированные колонки)

про индексы, да. чё толку хранить json, если по нему не найти ничего

ну мол мне казалось что колонки надо руками генерить

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

надо будет почитать чё там наворотили, пасиб.

ну и места жрет... хотя тут не разбирался

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

кто ты и куда делся кнопкодав?)

а шо? Вроде я всегда пишу такие капитанства =)

у меня на работе тоже сплошной мускуль, даже если новые проекты пилятся - тоже на мускуле. "Чтобы не разводить зоопарк". Обычная человеческая инерция

а, ну можно индекс на виртуальные генерируемые.. т.е. места не жрет...

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

в 8-ке вроде как есть uuid1

+ функции типа uuid_to_bin

и обратно

и is_uuid

что тебе еще надо?)

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

"чуть менее удобно" - хера себе у тебя высокий болевой порог. CREATE INDEX foo ON (some expression) vs создать поле самому + самому следить за обновлением этого поля из выражения + создать индекс)

+ киллер фича индексов постгри - CREATE INDEX ... WHERE some condition

которая некисло так оптимизирует всякие хитрые штуки

зачем следить? генерируемые колонки - это выражение

прикольно, не видел такого

постгрес так не умеет)

https://dev.mysql.com/doc/refman/8.0/en/create-table-generated-columns.html это в 8.0 завезли

вроде в 5.7 еще было (судя по доке)

ну да, постгресу придется тригер вешать... в 5.7 только в ndb вроде

таки да...

просто в постгрессе как бы вьюшки есть)

материализованные

потому как бы никогда не испытывал такой необходимости. Но выходит что на 8-ом мускуле вполне можно жить с json

а может и в 5.7... нужно разобораться ну да, можно... правда привется обращаться к колонкам, а не по выражениям

а может и в 5.7... нужно разобораться ну да, можно... правда привется обращаться к колонкам, а не по выражениям

?

да я просто подумал, что 5.7 только в ndb завезли...

p.s. если кто-то может мне рассказать хотя бы в контексте 1% проектов почему mysql в чем-то лучше постгри - буду признателен. Аргумент "потому что я знаю мускуль" не принимаю

перкона есть со своими тулзами, те же движки rocks и toku впиливают, можно поиграться, ну и движуха вокруг мускла пока еще поактивнее, у постгре для меня самый большой плюс это компиляция за 10 мин в отличие от 1.5 часов мускла)

Вечер добрый господа разрабы. Никто не в курсе библиотеки, которая является мостом между разными форматами локалей. Чтобы можно было использовать примерно так: $locale = Locale::getInstance('en-US'); $locale->shortened(); //en $locale->full(); //en-US

explode(...)[0]; не?

explode(...)[0]; не?

Если так смотреть, то можно просто if else. А я хотел именно либу, со всем блекджеками и куртизанками

Если так смотреть, то можно просто if else. А я хотел именно либу, со всем блекджеками и куртизанками

я думаю, intl решает подобные задачи: http://php.net/manual/ru/book.intl.php http://php.net/manual/ru/locale.getregion.php http://php.net/manual/ru/locale.getprimarylanguage.php

Только не забудь расширение установить :)

я думаю, intl решает подобные задачи: http://php.net/manual/ru/book.intl.php http://php.net/manual/ru/locale.getregion.php http://php.net/manual/ru/locale.getprimarylanguage.php

Спасибо, тыкнул как-раз в то, что нужно. А то сам не нашёл

Хм, какая странная фигня. Хочу настроить 2 dbal подключения (пока клонировал одно и то же, но не суть)