How to become an author
Search
Write a publication
Pull to refresh

Comments 29

Интересно. Но я все-равно боюсь монго в продуктиве…
Total votes 4: ↑2 and ↓20
В качестве основного хранилища – я тоже боюсь, но для некоторых задач вполне ок.
This comment wasn’t rated yet0
А чего имеено боитесь? Отсутствия транзакций или неуверенности в собственных силах?
Total votes 3: ↑3 and ↓0+3
Как основную ее использовать нельзя — отсутствие связей.
Total votes 10: ↑1 and ↓9-8
Имеете ввиду внешние ключи? Или что-то иное?
Я 2 года пишу проект с использованием монги, где не менее полусотни моделей, связанных между собой.
Имеется несколько миллионов зарегистрированных юзеров (т.е. не студенческий проект) и не столкнулся с особыми проблемами.
Есть только одна — транзакции.

Автор статьи очень правильно сказал:
MongoDB не требует описания схем таблиц благодаря чему вы можете с легкостью сохранять объекты, и таким образом быстрее приспосабливаться к изменениям в требованиях...

Это я чувствую каждый день на себе.
Total votes 1: ↑1 and ↓0+1
Ну я скажу так. У вас есть студенты и парты. Как вы это опишите?
Как-то так?

{
  "students":[
    {
      "name": "ivanov",
      "table": {
        "id": 1
      }
    },
    {
      "name": "petrov",
      "table": {
        "id": 1
      }
    },
    {
      "name": "sidorov",
      "table": {
        "id": 1
      }
    }
  ]
}

Задача — посчитать количество парт.
Нужно перебрать всех студентов, если не ошибаюсь.
Total votes 1: ↑0 and ↓1-1
Нет.
Я делаю точно так же как и в реляционной модели если я знаю что у меня не должно быть ограничений по объему данных.
user collection
[
	{
		_id: 1,
		name: "Vasia"
	}
]

student collection
[
	{
		_id: 123,
		user_id: 1,
		start_time: 1369925201,
		end_time: 1369925201
	}
]
This comment wasn’t rated yet0
А где здесь парты? Ну вообще идеальный вариант многие ко многим. Я говорю, что никто не следит за целостностью данных. И это плохо для вас.

image
Total votes 5: ↑3 and ↓2+1
Модель у меня следит за целостностью.
Для решения проблемы многие ко многим использовал бы map/reduce ну или как вариант теже три коллекции как и в реляционной модели.
This comment wasn’t rated yet0
Тоесть никак не возможно, что в «третьей» коллекции(что описывает отношения) запись есть, а id таких нет? И удаляете вы такие записи вручную? С полной увереностью, что нигде не останеться «зависших» id?
И уверены, что работает это быстрее чем SQL решение, что само за всем следит?

Я уверен, что Монго прекрасна как промежуточная БД. Но пока я не стал бы хранить там данные, которыми дорожу. Например, будь я банком.
Total votes 2: ↑1 and ↓10
«в «третьей» коллекции запись есть, а id таких нет» — это проблема в голове. Одинаково плохо можно использовать и nosql и sql, поэтому этот пример ничего не доказывает.

«SQL решение, что само за всем следит» — соглашусь, это иногда может быть удобно, но за это удобство вы заплатите производительностью и сложностями в проектировании и модифицировании структуры данных.

Да «банковские» задачи без транзакций не решаются. А их в монге нет.
Ну и я не банк и настолько критичных данных у меня нет, а есть ли они у 80% разработчиков?
В вашем примере про парты их тоже нет.

А все остальное сделать можно, работает очень быстро, разработка гораздо проще.
Total votes 3: ↑2 and ↓1+1
Можно подробнее о третьей записе?
То есть есть 2 коллекции у каждого элемента title, припустим. А что хранится в коллекции, что их связывает? Копии элементов с первых двоих?
This comment wasn’t rated yet0
ну говорил жу уже есть два варианта.
1) делать так как пишут во всех примерах для nosql
2) так же как вы делаете в релационной БД, но собирать все нужно «вручную» (у меня это делает модель).
post._id
post.title
tag._id
tag.title
post_tag._id
post_tag.post_id
post_tag.tag_id
This comment wasn’t rated yet0
А, понял. Вы пишите:
«в «третьей» коллекции запись есть, а id таких нет» — это проблема в голове.

Хотя поверьте — случай вполне реальный.
This comment wasn’t rated yet0
Согласен, что реальный, сам такое «творил», все мы когда учились… но это не повод теперь отказывать себе в удовольствии поработать с удобным и быстрым инструментом.
This comment wasn’t rated yet0
Когда учились? Просто забыл, что еще где-то на эту запись есть ссылка и все. Когда команда большая можно какую-то связь и упустить.
Наверное это чисто мое субъективное. Но в SQL базе как-то спокойнее себя чувствую. А в mongo через длительный промежуток времени такой срач.
This comment wasn’t rated yet0
Да «банковские» задачи без транзакций не решаются.

Вполне решаются. Типичная задача перевода с одного счёта на другой:
В 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;
и последующей выборки из таблицы account по нужному id счёта, когда нам нужно получить баланс счёта.

В 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.
This comment wasn’t rated yet0
Что делать, если суммы транзакции уже нет на счете в момент списания?
Total votes 2: ↑2 and ↓0+2
Разные варианты есть. Как минимум зависит от того, а что собственно надо делать — у нас отрицательный баланс допустим.
This comment wasn’t rated yet0
Разве так считать не дольше будет?
Total votes 1: ↑1 and ↓0+1
Транзакции (атомарномть), связи сущностей, а главное — что будет если… (тут много вопросов, ответы на которые надо искать опытным путем, что требует времени которого обычно на упражнения нет).
Total votes 3: ↑2 and ↓1+1
А почему grunt? Не лучше ли было бы использовать gulp?
Да, там сейчас меньше библиотек, но все основные есть, а главное — он прививает тягу к качеству кода: нет необходимости удалять промежуточные файлы, потому что этих файлов не появляется, можно легко и просто настроить отдельные вотчеры на отдельные пути, ну и конфигурация почитаемее будет.
Total votes 4: ↑1 and ↓3-2
Вероятно потому, что галп пока ещё не мейнстрим.
This comment wasn’t rated yet0
У меня и в grunt не появляется промежуточных файлов, и вотчеры все отдельные, ЧТЯДНТ?
This comment wasn’t rated yet0
Да, альтернативы 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. Либо она отпадет в каком-нибудь новом языке.
Total votes 2: ↑1 and ↓10
правы-правы. я до сих пор немного в шоке от того что там есть честные Map-ы и дефиниция noSuchMethod, и я уже даже не пытаюсь понять как оно работает.
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr