иначе костыли

а что, носклу уже нужен орм?

там ведь совсем другие принципы разработки

если юзается носкл + орм фреймворк, то что?

или я что-то упустил

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

реалии требуют орм носкл

Нихера это не реалии, а маркетолухи

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

Нихера это не реалии, а маркетолухи

я не говорю что так надо делать

если юзается носкл + орм фреймворк, то что?

есть такой кейс, да

ну, по крайней мере с моей стороны никаких требований к алхимии по поддержке nosql нет

есть такой кейс, да

вот именно я о нем

главный упор на поддержку как раз sql субд

ну, по крайней мере с моей стороны никаких требований к алхимии по поддержке nosql нет

ты в проектах носкл юзаешь хоть где нибудь?

главный упор на поддержку как раз sql субд

давай реально смотреть

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

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

жирные таблицы можно загонять в носкл, но это из области оптимизации

так не надо делать, если не припрёт

ты в проектах носкл юзаешь хоть где нибудь?

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

nosql вообще мало кому нужная штука, но модно, да

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

я не обсуждаю щас сам носкл как таковой

У меня весь проект на работе на NoSQL - что бы ему пусто было.

nosql вообще мало кому нужная штука, но модно, да

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

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

чисто без носкл, алхимия тоже не нужна, она слишком избыточна

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

если надо юзать сильно бд, лучше перейти на процедуры сразу это будет гораздо эффективнее

по носклу есть прекрасные статьи https://highlyscalable.wordpress.com/2012/09/18/distributed-algorithms-in-nosql-databases/ которые раскладывают всё по полочкам

если же нет, 90% фич алхимии тупо не нужны

по носклу есть прекрасные статьи https://highlyscalable.wordpress.com/2012/09/18/distributed-algorithms-in-nosql-databases/ которые раскладывают всё по полочкам

носкл вообще не нужен

а там есть выводы - что современные субд вшивают в себя разные детали от носкл решений

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

например логи, парсинг и тд

для этих кейсов еще можно юзать

а там есть выводы - что современные субд вшивают в себя разные детали от носкл решений

есть такое, но это больше в угоду тренду

ну так изначально вопрос был про алхимию

а не про nosql

в контексте текущих проектах с носкл и алхимией это показывает ее недоразвитость

тот факт, что алхимия не поддерживает nosql не делает её плохим проектом) она вообще не про nosql

а это реальный кейс

неумение джанго варить кофе тоже доказывает её недоразвитость

тот факт, что алхимия не поддерживает nosql не делает её плохим проектом) она вообще не про nosql

сама по себе она тоже не нужна

она избыточна

а варить кофе - это реальный кейс

а варить кофе - это реальный кейс

твои домыслы

У меня весь проект на работе на NoSQL - что бы ему пусто было.

какая именно?

а варить кофе - это реальный кейс

??

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

какая именно?

Самая модная :) - MongoDB

неумение джанго варить кофе тоже доказывает её недоразвитость

вот и я об этом)

а это ключевая вещь в грамотно построенных системах

с энтропией невозможен эффективный проект

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

но это я хз...

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

энтропия

если в проекте 10 типов хранилищ, 10 типов доступа к ним, но это хуйня а не проект

он сдохнет под своей тяжестью

оверхед на поддержку будет конский

Самая модная :) - MongoDB

а ну да, пиздец ))

вот монга точно не нужна

вот монга точно не нужна

А что нужно?

А что нужно?

мускуль :)

как ты мог забыть

https://pbs.twimg.com/media/BNELF1GCUAExynU.png

окей, кроме отсутствия поддержки nosql если ли какие-то другие претензии к алхимии?

У меня данные разной структуры.

В одной таблице.

Для логов и аналитики - Monga вполне себе нормально так

ERROR: S client not available

мускуль/постгря + джейсон

MySQL не подойдёт.

мускуль/постгря + джейсон

Медленно, давай быстрее.

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

окей, кроме отсутствия поддержки nosql если ли какие-то другие претензии к алхимии?

избыточность

Медленно, давай быстрее.

кассандра

кассандра

Крутая штука! Не спорю даже.

избыточность

но ведь это можно сказать про любой ORM?

Часто выбираю между MongoDB и Cassandra.

MySQL не подойдёт.

почему

но ведь это можно сказать про любой ORM?

нет, пиви не избыточен

почему

Много документов с разной структурой, не прописывать же DEFAULT NULL везде.

Вложенные массивы там.

Поля разные.

Это аналитика.

Много документов с разной структурой, не прописывать же DEFAULT NULL везде.

а

Я и не говорил что MySQL не нужен, я про свой кейс текущий.

я бы в этом случае в txt кидал бы :)

Где у нас используется MongoDB.

все равно лучше

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

https://www.youtube.com/watch?v=APyz8Ye0IxE

а постгря прям вообще медленно для твоих задач?

я бы в этом случае в txt кидал бы :)

Map-reduce нужен и выборки.

а постгря прям вообще медленно для твоих задач?

нет но он требует много администрирования

а постгря прям вообще медленно для твоих задач?

Через BSON да, и там та же проблема со структурой.

Map-reduce нужен и выборки.

мусор в txt потом нормализовать все

там же можно в джейсон херачить структуры данных и не париться по схеме

но для такого монга пойдет

Через BSON да, и там та же проблема со структурой.

а в xml хранить и по полям индексить?

там же можно в джейсон херачить структуры данных и не париться по схеме

Так я и говорю, медленно.

Через BSON в PostrgreSQL.

Через BSON в PostrgreSQL.

даже так, ни куя ж себе