Laravel нужна помощь в проекте с Laravel

  • Автор темы Автор темы stuchin
  • Дата начала Дата начала
В монго нет ничего хорошего кроме рекламы и минимального уровня вхождения, чтобы новички хавали, пачкая себе рот коричневым и плохо пахнущим продуктом.
Не, ну они понемногу исправляются. Недавно вот узнали, что mmap() - не всегда самый эффективный способ работы с диском. :) И даже document-level locks делают! Этак и до версионного движка недалеко (тут, правда, потребуется пересилить себя и прочитать какую-нибудь книжку о внутреннем устройстве РСУБД). Хотя уже есть TokuMX, хоть и на хаках построенный и с откровенным маркетинговым звездежом про performance, но все же.
 
Советую всем сомневающимся посмотреть одну из лекций Олега Бартунова о добавлении hstore, jsonb и создании индексов для этих типов данных.

Да, хорошая лекция. Если кто не знает - http://ru.linkedin.com/in/olegbartunov - он занимался разработкой СУБД, когда пейсатели монги еще пешком под столом ходили.
 
я вот думаю какое отношение имеет лекция Бартунова к теме топика, есть PostgreSQL и хорошо, много еще всяких баз есть, зачем здесь это обсуждать.
Я верю что Бартунов молодец и база его хорошая, опять же к теме не имеет ни какого отношения.
 
stuchin, согласен, что лучше здесь обсуждать не стоит, но вот выбор монги очень странно выглядит, чем он обоснован?
 
stuchin, согласен, что лучше здесь обсуждать не стоит, но вот выбор монги очень странно выглядит, чем он обоснован?

в жизни много странного и непонятного, Бартунов в лекции ясно сказал , что новое время требует новых баз(NoSql), мне же надо чтобы клиент мог сам писать код по обработке данных с базы,

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

вариантов тут нет, либо лепить монстра (типа на крутой СУБД ), либо применить нестандартный подход .
Поскольку бюджета нет то выбор для меня только единственный, здравствуй MongoDB, прощай SQL.
Так я понятно объяснил?
 
мне же надо чтобы клиент мог сам писать код по обработке данных с базы,

SQL тут явно не подходит, полуграмотный клиент быстро превратит любую систему в черепаху живую или мертвую, или что хуже убьет структуру базы.
С прямым доступом к базе кому попало все убьют в любом случае, а с бесконтрольным NoSQL еще раньше, чем убьют, все превратится в помойку, с которой ничего нельзя сделать. Надо предоставлять API, а как запросы к нему преобразуются в запросы к хранилищу - дело внутренностей системы. jsonb в postgresql как раз позволит совмещать - хранить пользовательские данные в jsonb, давать делать выборки через jsquery, а системные данные и связи хранить надежно.

НО если уж так нравится API монги, советую посмотреть в сторону tokumx - та же монга, но без btrees, с версионным движком и транзакциями.
 
stuchin, то есть реальных аргументов нет, только хипстерское новое время требует новых баз(NoSql)

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

NoSQL никакая не новая базы данных, это то, что было до sql, файловые и dba были уже давно, а на смену им пришли реляционные базы данных, как раз чтобы решить проблемы, которые ты описал.
 
stuchin, согласен, что лучше здесь обсуждать не стоит, но вот выбор монги очень странно выглядит, чем он обоснован?
Ну плюс монги - можно научиться пользоваться ей за полчаса и использовать для своего говнокода.
Для SQL нужно больше знаний и времени (видно из высказываний выше).

Иначе ее популярность мне объяснить сложно.
 
Absinthe, ну, простота входа как раз обманчива. Да, пользоваться просто, но нужно самому следить за целостностью, строить схемы, следить за индексами и т.д, не зря почти все инструменты для работы с монгой требуют описание схемы для того, что теоретически schemaless database. Но для меня основная проблема в том, что под рукой нет ни одного админа-девопса, который бы мог админить монгу, особенно в случаях проблем или падения. Так что проблема как раз в моём незнании монги из-за высокого порога по администрированию.

Кстати, для mysql я пользуюсь простой схемой, если нужно ложить сложные структуры - ложу их в поле через json_encode - serialize, если нужен поиск, добавляю в таблицу соответственную ячейку и дублирую туда значение из структуры.
 
Последнее редактирование:
Ну плюс монги - можно научиться пользоваться ей за полчаса и использовать для своего говнокода.
Для SQL нужно больше знаний и времени (видно из высказываний выше).
SQL как раз простая вещь, та все до нас придумали, что там долго изучать, синтаксис оператора select?
А вот NoSql совсем другое дело, все надо руками делать.
 
Сверху