All streams
Search
Write a publication
Pull to refresh
0
0
Michael @SkiF_TLT

User

Send message
Добавил раздел «Среда обитания», где описал конфигурацию обеих СУБД.
Просто вы еще вторую часть не читали. Тут все гораздо хитрее )
По сути MongoDB и хороша тем, что вместо реляционных таблиц можно хранить все необходимые параметры в одной коллекции. Опять же, из серии «что конкретно нам нужно?». Если эти параметры не требуют постоянного обновления — то почему нет? В том же интернет магазине — у каждого товара может быть свой набор характеристик. Зачем только из-за этого делать отдельную таблицу с ними и каждый раз при отображении страницы юзать джойны, когда можно обойтись хранением всех данных товара в самом объекте этого товара, уже готовом? Завод-производитель очень редко когда меняет описание своего продукта.

А такое огромное преимущество во вставке — очень полезно при необходимости логирования каких-то действий. При этом, опять же, не нужно обновлять несколько связанных таблиц, объект может иметь уже все необходимы атрибуты с практически любым уровнем вложенности.

Результаты теста ни на чем не настаивают, они лишь дают пользователю понять, что надо отталкиваться от текущей необходимости, а не от «брэнда», «моды», «у Васи так же» и т.п.
Однако многие задаются вопросами «что выбрать SQL или no-SQL?».

Понятное дело, что принцип проектирования полностью меняется при переходе с одного на другое, однако можно же реализовать проект и так и эдак. У нас, например, используется и MongoDB и PostgreSQL. Тут смысл то в том, чтобы понять «а что мы вообще хотим»? Сравнение весьма поверхностно, но общую картину показывает (давайте я допишу вторую часть, а потом уже подытожу, не хочу заранее этого делать).

Information

Rating
Does not participate
Location
Тольятти, Самарская обл., Россия
Date of birth
Registered
Activity