Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Интересно. Но я все-равно боюсь монго в продуктиве…
В качестве основного хранилища – я тоже боюсь, но для некоторых задач вполне ок.
А чего имеено боитесь? Отсутствия транзакций или неуверенности в собственных силах?
Как основную ее использовать нельзя — отсутствие связей.
Имеете ввиду внешние ключи? Или что-то иное?
Я 2 года пишу проект с использованием монги, где не менее полусотни моделей, связанных между собой.
Имеется несколько миллионов зарегистрированных юзеров (т.е. не студенческий проект) и не столкнулся с особыми проблемами.
Есть только одна — транзакции.
Автор статьи очень правильно сказал:
Это я чувствую каждый день на себе.
Я 2 года пишу проект с использованием монги, где не менее полусотни моделей, связанных между собой.
Имеется несколько миллионов зарегистрированных юзеров (т.е. не студенческий проект) и не столкнулся с особыми проблемами.
Есть только одна — транзакции.
Автор статьи очень правильно сказал:
MongoDB не требует описания схем таблиц благодаря чему вы можете с легкостью сохранять объекты, и таким образом быстрее приспосабливаться к изменениям в требованиях...
Это я чувствую каждый день на себе.
Ну я скажу так. У вас есть студенты и парты. Как вы это опишите?
Как-то так?
Задача — посчитать количество парт.
Нужно перебрать всех студентов, если не ошибаюсь.
Как-то так?
{
"students":[
{
"name": "ivanov",
"table": {
"id": 1
}
},
{
"name": "petrov",
"table": {
"id": 1
}
},
{
"name": "sidorov",
"table": {
"id": 1
}
}
]
}
Задача — посчитать количество парт.
Нужно перебрать всех студентов, если не ошибаюсь.
Нет.
Я делаю точно так же как и в реляционной модели если я знаю что у меня не должно быть ограничений по объему данных.
Я делаю точно так же как и в реляционной модели если я знаю что у меня не должно быть ограничений по объему данных.
user collection
[
{
_id: 1,
name: "Vasia"
}
]
student collection
[
{
_id: 123,
user_id: 1,
start_time: 1369925201,
end_time: 1369925201
}
]
А где здесь парты? Ну вообще идеальный вариант многие ко многим. Я говорю, что никто не следит за целостностью данных. И это плохо для вас.
Модель у меня следит за целостностью.
Для решения проблемы многие ко многим использовал бы map/reduce ну или как вариант теже три коллекции как и в реляционной модели.
Для решения проблемы многие ко многим использовал бы map/reduce ну или как вариант теже три коллекции как и в реляционной модели.
Тоесть никак не возможно, что в «третьей» коллекции(что описывает отношения) запись есть, а id таких нет? И удаляете вы такие записи вручную? С полной увереностью, что нигде не останеться «зависших» id?
И уверены, что работает это быстрее чем SQL решение, что само за всем следит?
Я уверен, что Монго прекрасна как промежуточная БД. Но пока я не стал бы хранить там данные, которыми дорожу. Например, будь я банком.
И уверены, что работает это быстрее чем SQL решение, что само за всем следит?
Я уверен, что Монго прекрасна как промежуточная БД. Но пока я не стал бы хранить там данные, которыми дорожу. Например, будь я банком.
«в «третьей» коллекции запись есть, а id таких нет» — это проблема в голове. Одинаково плохо можно использовать и nosql и sql, поэтому этот пример ничего не доказывает.
«SQL решение, что само за всем следит» — соглашусь, это иногда может быть удобно, но за это удобство вы заплатите производительностью и сложностями в проектировании и модифицировании структуры данных.
Да «банковские» задачи без транзакций не решаются. А их в монге нет.
Ну и я не банк и настолько критичных данных у меня нет, а есть ли они у 80% разработчиков?
В вашем примере про парты их тоже нет.
А все остальное сделать можно, работает очень быстро, разработка гораздо проще.
«SQL решение, что само за всем следит» — соглашусь, это иногда может быть удобно, но за это удобство вы заплатите производительностью и сложностями в проектировании и модифицировании структуры данных.
Да «банковские» задачи без транзакций не решаются. А их в монге нет.
Ну и я не банк и настолько критичных данных у меня нет, а есть ли они у 80% разработчиков?
В вашем примере про парты их тоже нет.
А все остальное сделать можно, работает очень быстро, разработка гораздо проще.
Можно подробнее о третьей записе?
То есть есть 2 коллекции у каждого элемента title, припустим. А что хранится в коллекции, что их связывает? Копии элементов с первых двоих?
То есть есть 2 коллекции у каждого элемента title, припустим. А что хранится в коллекции, что их связывает? Копии элементов с первых двоих?
ну говорил жу уже есть два варианта.
1) делать так как пишут во всех примерах для nosql
2) так же как вы делаете в релационной БД, но собирать все нужно «вручную» (у меня это делает модель).
post._id
post.title
tag._id
tag.title
post_tag._id
post_tag.post_id
post_tag.tag_id
1) делать так как пишут во всех примерах для nosql
2) так же как вы делаете в релационной БД, но собирать все нужно «вручную» (у меня это делает модель).
post._id
post.title
tag._id
tag.title
post_tag._id
post_tag.post_id
post_tag.tag_id
А, понял. Вы пишите:
Хотя поверьте — случай вполне реальный.
«в «третьей» коллекции запись есть, а id таких нет» — это проблема в голове.
Хотя поверьте — случай вполне реальный.
Вот по теме нашлось
jsman.ru/mongo-book/Glava-4-Modelirovanie-dannyh.html
jsman.ru/mongo-book/Glava-4-Modelirovanie-dannyh.html
Да «банковские» задачи без транзакций не решаются.
Вполне решаются. Типичная задача перевода с одного счёта на другой:
В SQL решили бы как то-так (примитивная реализация):
START TRANSACTION;
UPDATE account SET amount = amount - :amount WHERE id = :debet_account_id;
UPDATE account SET amount = amount + :amount WHERE id = :credit_account_id;
COMMIT;
В MongoDB и подобных СУБД решается путем создания документа в коллекции transaction типа
{
amount: :amount,
debet_account_id: :debet_account_id,
credit_account_id: :credit_account_id
}
и последующем применении reduce как суммы всех amount для нужного debet_account_id за вычетом суммы всех amount для нужного credit_account_id.
Монго умеет MapReduce
Транзакции (атомарномть), связи сущностей, а главное — что будет если… (тут много вопросов, ответы на которые надо искать опытным путем, что требует времени которого обычно на упражнения нет).
Автор yeoman не ценит явно addyosmani.com/blog/full-stack-javascript-with-mean-and-yeoman/.
Мне кажется велосипед, мог бы просто свой генератор для yeoman'а написать.
Мне кажется велосипед, мог бы просто свой генератор для yeoman'а написать.
А почему grunt? Не лучше ли было бы использовать gulp?
Да, там сейчас меньше библиотек, но все основные есть, а главное — он прививает тягу к качеству кода: нет необходимости удалять промежуточные файлы, потому что этих файлов не появляется, можно легко и просто настроить отдельные вотчеры на отдельные пути, ну и конфигурация почитаемее будет.
Да, там сейчас меньше библиотек, но все основные есть, а главное — он прививает тягу к качеству кода: нет необходимости удалять промежуточные файлы, потому что этих файлов не появляется, можно легко и просто настроить отдельные вотчеры на отдельные пути, ну и конфигурация почитаемее будет.
Да, альтернативы JavaScript’у рождаются каждый день, например, CoffeeScript, TypeScript и миллионы языков, которые компилируются в JavaScript. Эти альтернативы могут быть полезными на этапах разработки (благодаря source maps), но им не удастся заменить JavaScript в долгосрочной перспективе по двум причинам: их сообщества никогда не станут больше, и их лучшие возможности будут реализованы в ECMA Script (читай: JavaScript).
CoffeeScript и подобные (IcedCoffee, не уверен насчет TypeScript, но точно не Dart) — не альтернативы, а синтаксический сахар, и они никуда не денутся в долгосрочной перспективе, потому что как бы ни развивался ECMA Script, ему придется сохранять совместимость синтаксиса с javascript, и эти нагромождения скобок никуда не денутся.
К тому же, «официальный» стандарт — это всегда компромисс, разработчики пытаются угодить всем понемногу. Те же отступы — кто-то жить без них не может, а кого-то воротит, а придется выбирать что-то одно. Да и времени на внедрение новых возможностей у них уходит немало.
Плюс, каждая новая возможность усложняет язык, ее нужно как-то вписать в существующий синтаксис, не забудем громадную армию программистов, которым нужно эту возможность тоже изучить, даже если не хочется, потому что кто-то другой может ее использовать и придется разбираться…
В общей сложности все эти факторы устанавливают определенный потенциальный потолок, преодолеть который ecmascript в чистом виде не получится. А вот производным от него — вполне.
JavaScript это не язык ассемблера, это высокоуровневый язык программирования с исходных кодом, который вы можете понять, так что вы должны понять его.Для вас может быть сюрпризом, но есть люди, которые могут читать ассемблер. Вопрос в том, хотят ли. Я вот тоже не очень горю желанием читать генерируемый CoffeeScript'ом js-код. Да, разобраться можно, но приятным чтением не назовешь. А если сделать высокоуровневый DSL, в котором одна строчка будет транслироваться в десятки, а то и сотни строк javascript, вам тоже на захочется лезть под капот. При достаточном уровне качества трансляции, такой необходимости просто не будет. Часто ли современные разработчики прикладных приложений на C++ лезут в дизассемблер? Или Java/.NET-разработчики читают байт-код? Я пока не изучал Dart, так что поправьте, если я не прав, но там уже нет необходимости знать javascript. Либо она отпадет в каком-нибудь новом языке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Init.js: Зачем и как разрабатывать с Full-Stack JavaScript