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

если ты знаешь sql, всё вокруг кажется таблицами и их отношением )

Я спрашиваю именно про отсутствие схемы. Потому что там есть всякие плюсы того и того, но вот вопрос именно о "мы делаем agile, схема заранее не известна - поэтому монга"

ну, честно говоря, хз. даже если в процессе работы потребуется перепроектирование системы. то в sql надо будет модифицировать таблицы, либо создать другие и из них данные перенести. всё это - манипуляции с данными. в sql это быстрее происходит. в плане времени разработки. делаются sql запросами и без программирования. или о чем речь? на сколько адаптивны оба подхода к измнению ТЗ?

недостаточно выбрать кодировку, надо ещё сервер тюнить http://stackoverflow.com/questions/6172798/mysql-varchar255-utf8-is-too-long-for-key-but-max-length-is-1000-bytes

а то лимиты на индексы со всех щелей будут мешать жить

в utf8 не может быть однобайтного символа с кодом 132 (0x84) там только до 0x7f, потому он его дополняет 0xc2, я не уверен, но думаю что приводит его к управляющему символу (они как раз с 0xc2 начинаются)

не знать SQL в 2017 это странно. гнать таких программистов ссаными тряпками!

я пока видел все проекты что на NoSQL через какое то время если они все еще живы постепенно переезжают на РСУБД. Потому что внезапно им становятся нужны нормальные транзакции и схема уже устаканилась

а если разработки не знает SQL то пусть хоть ORM тогда возьмет

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

до таких потребностей надо еще дорости )

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

Да, ssd конечно решает сейчас. Раньше было печально с произодительностью у реляционных.

все конечно пилят проекты и аргументируют выбор монги что вот к нам куча юзеров придет и нам нужна монга. ага прям в первый день 1 лям юзеров. не видел такого. максимум всплески был там хорошие после рекламных акций дак и РСУБД держат норм. потому что у всех норм системах впереди стоит горячий кэш

Да нормально все было

У меня просто на работе mean от которого бомбит просто пздц

Только вместо express ещё и loopback

10м записей на селероне в 2006 году. Муsql под виндой. Только схему правильно спроектируй и индексы

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

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

Ну я видел пару не верных загибов и на sql

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

на ангуляр зря батон крошишь, хорошая технология и тормозит он не больше чем тот же реакт в кривых руках

А я и не говорю, что среди фронтенда есть не говно

Ребят, вот чисто чтобы потрещать - кто считает отсутствие схемы данных в nosql преимуществом по сравнению с sql ?

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

Я только первый знаю. Норм. Но с ходу тяжело

но в целом ситуация с mean такая как вы описали =)

куча новичков мучаются, потому что он не простой для входа

а опытные товарищи выбирают уже другие инструменты

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

А вообще я на прошлой работе писал все на монге, потом заебались и перевели проекты на постгрес и стало заебись

у меня лично монга нигде не прижилась (((

Потому что один хуй всегда схема есть

А среднестатистический программист на жс - это чувак который нихрена не программист. Знает стек, может сделать на нем работу, но гарантированно херово

И кроме 2 фреймворков не знает ничего

Делает могну потому что "не надо схему задавать"

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

Тесты - нахер

Профилирование - вообще что это

А как их там делать?

Как сделать тесты для express и монги - я даже знаю

Как для фронта - используют фантомы всякие

Для апп на ангуляре

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

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

Поэтому в любом аппе от mean программера: query={}, А потом в контроллере будем фильтровать и джойнть

парни

https://pragprog.com/book/nrwebpay/take-my-money

четкая книжечка

должна быть, сам не читал

JSONB из Postgresql хватит на всех )

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

это если хз что там со схемой вначале

это если хз что там со схемой вначале

Значит ты манкикодер а не программист

это совет тем кто на монге

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

это если хз что там со схемой вначале

не бывает так, что совсем хз. все равно данные - это какие-то объекты. по ним будут таблицы. а изменения все - ну поля добавятся. и еще таблицы.

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

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

разносить по колонкам хорошо, потому что JSONB не готов для постоянного хранения сырой кучи данных [в pg по крайней мере]

именно. как временное решение

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

Ну как минимум один раз.

именно. как временное решение

места зажирает нереально много. как оказалось, словарь ключей есть у каждого кортежа :D

Значит ты манкикодер а не программист

а вот это обидно за 11 лет стажа разработки услышать )

а вот это обидно за 11 лет стажа разработки услышать )

Ну я это писал не тебе конкретно. Хотя, если после 11 лет разработки тебе все ещё не понятна схема данных в начале...

Я полагаю что понятна

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

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

ERROR: S client not available

ага. еще напиши, что мы все умрем

Ну я это писал не тебе конкретно. Хотя, если после 11 лет разработки тебе все ещё не понятна схема данных в начале...

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

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

У меня такого не бывало, видео мало опыта. Если у тебя в принципе много провайдеров, то ты никакой схемы кроме jsonb и не придумаешь. А если через полгода после запуска поменяли одну апиху на другую - можно и минрацию сделать

И я не говорил что схема не ясна ПОЛНОСТЬЮ. Схема ясна на базовом уровне на процентов 80. Т.е. есть таблица с полями, а вот к примеру параметры для этой сущности пока не ясны. Удобнее их сделать полем JSONB. Потому что воротить тут EAV себе дороже, и хранить как то по другом не удобно. А когда с этими данными будет все ясно, определимся как хранить

А я тогда имел в виду чуваков, которые не могут выделить 80% и думают что у них 100% - как твои 20

Другой кейс который я видел был на проекте в госсекторе. Ребята хранили в JSONB оригинальный ответ от стороннего АПИ, для разбора конфликтных ситуаций. Типа АПИ ответил не как обычно, прилетело то что раньше никогда не было. А такое часто бывает на госуслугах.

И я не говорил что схема не ясна ПОЛНОСТЬЮ. Схема ясна на базовом уровне на процентов 80. Т.е. есть таблица с полями, а вот к примеру параметры для этой сущности пока не ясны. Удобнее их сделать полем JSONB. Потому что воротить тут EAV себе дороже, и хранить как то по другом не удобно. А когда с этими данными будет все ясно, определимся как хранить

Еще бывает что требования меняются и надо дополнить схему. Тогда можно достать сохраненное из jsonb

Ну вот да. Я эти кейсы и имел в виду что дополнил Марат

Так он вообще может ответить некорректным json - ом которое в поле не полезет. Не лучше просто все ответы логгировать как текст тогда?

я не знаю. но у ребят это решение работает. совсем некорректного жсон на 1 мб у них еще не было

А вот как думаете, с точки зрения конкурентоспособности есть смысл ruby/rails подучить?

я бы Java лучше выбрал на подучить

Почему её?

заката Java пока нет и не предвидится, а вот с руби обратная история

Ну джаву я хоть боль-мень знаю, и C, С++ хорошо. Питон думаю отлично знаю.

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

Конкретно в вебе.

товарищи

че то туплю

есть переменная a которая хранит в себе строку "a"

То-то всякие котлины и ему подобные появляются

заката Java пока нет и не предвидится, а вот с руби обратная история

как получить ее юникод значение

ну 97 тоесть

?a

не предлагать, это как бы логично, но мне нужно именно у переменой значение получить

String.first

Ну джаву я хоть боль-мень знаю, и C, С++ хорошо. Питон думаю отлично знаю.

Тогда за конкурентоспобность нечего опасаться)

String.first

iex(21)> a = "a" "a" iex(22)> String.first(a) "a"

1.4.2 IEx

А, тебе код нужен

ага