Дизайн базы данных: Mysql или MongoDb/OrientDb для сопоставления отношений?

Question

Мне нужен совет.

Я разрабатываю веб-приложение, написанное на PHP с несколькими объектами, но много (по количеству и типу) отношения.

Простые примеры:

• Entities: 4
• Возможные ManyToMany отношения и OneToMany и OneToOne: дюжин

Сегодня, это имеет смысл продолжать использовать для отображения отношений RDMS как MySql или лучше использовать графическую базу данных, такую ​​как OrientdDb, или документ-ориентированный db, такой как MongoDb?

Я думаю, что лучше работать с сущностями в mysql и отношениями между объектами в OrientDb или MongoDb. Во время вставки объекта я могу реплицировать некоторые свои данные для управления отношениями, избегая десятков объединений между таблицами, избегая огромных индексов и с более быстрой вставкой/обновлением в Mysql.

Я делаю неправильно?

Answer 1

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

Более подробное описание вашего домена может помочь дать вам хороший совет. В любом случае я мог бы сформулировать эти две вещи:

1. Не используйте манго для отношений! Если есть вещь, которую Mongo НЕ предназначен для управления, это отношения.
2. Если вы планируете использовать Orient для управления отношениями графа, и вам также не нужно много нормальных отношений (нормальный характер, я имею в виду), не беспокойтесь, используя MySQL и Orient: идите только на Orient.

И, конечно, иметь в виду, что MySQL не представляет никакой опасности для хостинга, Монго является получение некоторый импульс (ObjectRocket и ServerGrove оба обеспечивают облако Монго услуг из коробки, но вы будете иметь жесткий время нахождения монго на «дешевом» общедоступном хостинге), в то время как для Orient я думаю, вам придется отправиться в выделенный серверный/облачный экземпляр и настроить службу самостоятельно.

Answer 2

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

Во-первых, противоречит @StickGrinder:

Не используйте Монго для отношений! Если есть вещь, которую Mongo НЕ предназначен для управления, это отношения.

MongoDB может обрабатывать отношения прекрасно это все о , как вы видите отношения как управляются.

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

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

У MongoDB есть много провайдеров от MongoLabs до ObjectRocket, и многие веб-хостинг-провайдеры (такие как AWS и Heroku) обеспечивают легкий доступ к пакетам MongoDB. На AWS вы можете получить полные облачные шаблоны, которые предварительно настроят дешевый (по сравнению с тем, сколько он должен стоить хозяину) кластера для черепов реплик.

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

Сегодня, это имеет смысл продолжать использовать для отображения отношений RDMS как MySql или лучше использовать базу данных графа как OrientdDb, или документ-ориентированной БД как MongoDb?

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

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

Я думаю, что лучше работать с объектами в MySQL и отношений между субъектами в OrientDb или MongoDb

Почему отдельные санитаров? Просто пойдите для MySQL, если это то, что вам нравится. MySQL будет более чем соответствовать вашим потребностям.

Во время ввода объекта я могу реплицировать некоторые данные для управления отношениями, избегая десятков объединений между таблицами, избегая огромных индексов и с более быстрой вставкой/обновлением в Mysql.

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

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

Это несколько указателей.