Yii Framework

samdark писал(а): ↑2019.08.16, 20:58 Если вам будет его нехватать, то сделать его самому в index.php — проще простого.

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

Так мы и не хотим чтобы service locator был общей практикой.

uEhlO4a писал(а): ↑2019.08.15, 00:16 по поводу ACID и заказа за который не оплатили, то хочу сказать, что только благодаря ACID клиент смог его вообще сьесть

ACID не всегда работает. Представьте сайт бронирования путешествий. Необходимо забронировать билет на самолет, гостиницу и такси в рамках одного бизнес-процесса. Сделать атомарно такое невозможно. Используют Saga pattern. Большинство бизнес-процессов в нашем мире не атомарны и для людей это нормально, соответственно нормально и для модели бизнес-процесса.

uEhlO4a писал(а): ↑2019.08.15, 00:16 NoSQL треш вроде сдулся, или не совсем? Я не особо за этим слежу просто.

Не сдулся. Для распределенных систем не работает ACID и JOIN из классических для PHP рсубд. Убираем это и остается объектно-реляционное несоответствие и ноль преимуществ. Используют потому что так учат книги/курсы, а по другому не умеют/не знают.

По тому что вижу, этот "Saga" https://blog.couchbase.com/saga-pattern ... ices-part/ это https://martinfowler.com/eaaDev/EventSourcing.html которое доказало свою нереальную сложность, по крайней мере в моей практике я таким не страдаю. Также ты наверно не до конца понимаешь, что такое "распределение". В этой Saga есть понятие "centralized service", по сути какая-то одна штука которая все равно будет ОДНА и будет разруливать то, что делает база данных, только в Х-раз дольше из-за криворукости + теряется целостность, т.к. событие уходит в очередь - когда очередь переполняется то тот бизнес сложит лапки.

Если нужны кластеры данных - для этого есть кластеры данных. Понимаешь? Пример https://www.mysql.com/products/cluster/
в отличии от текущего состояния ИТ сферы, раньше в этом поле работали професионалы, а не тупые хипстеры, которые выдумывают "прикольные" слова быстрее, чем успевают их запоминать своими одноклеточными мозгами. И это печаль

Насчет ACID - это Atomicity, Consistency, Isolation, Durability
Существует примерно 4 уровня изоляции. Есть разный подход репликаций и т.д.
ACID никаким боком не относится к NoSQL. Это 2 разные технологии. Они не взаимоисключающие. https://docs.mongodb.com/manual/core/transactions/


Но я не спорю, для дерьма вроде твитера или фейсбука, где потеря тупых комментариев ничего не означает, можно и блокнот использовать с побитовым чтением.
вот примерный разбор twitter https://www.8bitmen.com/what-database-d ... deep-dive/
как видишь, для хранения денег и твоих персональных данных (которые они потом продадут) используется MySQL, а для всякого пользовательского дерьма - всё что только угодно, т.к. это не имеет никакой ценности (к слову, в MySQL можно отключать изоляцию, врубить кеш на 90% памяти и будет та же тема, только минус будет в размере запроса и JOIN, потому и используют подход с хеш-ключами, т.к. это проще для разработчика и для сети)

Касаемо всякой фигни вроде couchDB WakandaDB myMegaCoolDB и остальной ерунды - главное не забывать проговаривать слова "highload" и "microservice", без них не по фен-шуй получается и не так круто ездить по ушам лохов.. потом клиенты упираются - "хочу mongoDB - слышал она быстрее", ну ок, уже выгребает из-за плохого индексирования по полям


п.с.
в общем, моя твоя не понимать. Давай пример, где ты используешь "Saga pattern" - сколько миллионов пользователей/заходов и т.д.? Или ты на 1.5 инвалидах это применяешь? Я с сайтами до 100к пользователей работаю, чтобы понятней было

п.п.с.
https://nickcraver.com/blog/2016/02/17/ ... 6-edition/

uEhlO4a писал(а): ↑2019.08.28, 12:46 раньше в этом поле работали професионалы, а не тупые хипстеры, которые выдумывают "прикольные" слова быстрее, чем успевают их запоминать своими одноклеточными мозгами. И это печаль... Касаемо всякой фигни вроде couchDB WakandaDB myMegaCoolDB и остальной ерунды - главное не забывать проговаривать слова "highload" и "microservice", без них не по фен-шуй получается и не так круто ездить по ушам лохов.. потом клиенты упираются - "хочу mongoDB - слышал она быстрее", ну ок, уже выгребает из-за плохого индексирования по полям

Можно и обратное сказать. Профессионалы из тех же Twitter и иже с ними для таблиц, значений, документов, графов, объектов, поиска и статистики используют специально для них придуманные и оптимизированные табличные, key-value, документные, графовые, объектные, поисковые и колоночные БД. И только "одноклеточные" SQL-щики на всё готовы, чтоб только из мантры "транзакции ис каропки" во все места впихнуть SQL и выгребают обходы графов. Та же печаль, только в профиль.

ElisDN,
ха-ха. твои аргументы норм работают при разводе недалеких людей псевдокурсами, но вот в реальном мире всё совсем по-другому.
Это твое "Профессионалы из тех же Twitter и иже с ними для таблиц, значений, документов, графов, объектов, поиска и статистики используют специальн.." вообще что-то непонятное. Какие графы? ты о чем вообще? GraphQL не имеет ничего общего с базой данных, и если в какой-то момент один с хипстеров занес им FlockDB , то он с такой же скоростью оттуда и уехал. Это чтобы ты понимал https://github.com/twitter-archive/flockdb

"обходы графов", ха-ха. жги еще!

кстати,
1. поисковых бд нет - есть поисковые движки, можешь почитать https://www.elastic.co/products/elasticsearch - они даже так и пишут ENGINE
2. колоночные бд - это сам придумал или кто подсказал? (п.с. а, вижу, есть ClickHouse , какая-то фигня от яндекса https://github.com/yandex/ClickHouse)
3. обьектные бд, key-value и остальной треш - это одно и тоже noSQL, то есть без конкретной схемы для данных, по сути BLOB . И они все одинаковы впринципе, за исключением поддержки транзакций и типов репликаций. ха-ха

аминь

uEhlO4a писал(а): ↑2019.08.28, 19:44 Какие графы? ты о чем вообще? GraphQL не имеет ничего общего с базой данных...

"обходы графов", ха-ха. жги еще!

Понятно. Больше вопросов не имею

Ну вот... получилась ещё одна монстротема обо всём и сразу с холиваром. Прикрываю. Давайте общаться более сфокусировано.