Выбор СУБД для проекта, Mongo / Rethink || SQL |
Здравствуйте, гость ( Авторизация | Регистрация )
Выбор СУБД для проекта, Mongo / Rethink || SQL |
09.11.2016, 23:08
Сообщение
#1
|
|
Продвинутый геймер Репутация: 112 Группа: Забанен Сообщений: 499 Награды: 3 Регистрация: 26.12.2009 |
Всем доброго gameru.net!
Имеется дилемма, о том, какую СУБД выбрать для проекта. В проекте подразумевается существование функций чата между <n> пользователями. Хранение сообщений должно быть таким, чтобы при удалении сообщения у пользователя <n> i-ого, сообщения сохранялись у остальных пользователей, поэтому я подумал, что сообщения лучше хранить в документо-ориентированных бд. Собственно, выбор пал на Rethink / Mongo. Что бы вы могли посоветовать, какой был бы Ваш выбор? -------------------- |
 
|
|
|
|
10.11.2016, 12:50
Сообщение
#2
|
|
You're never too young to have a plan. © Репутация: 2131 Группа: Участник Сообщений: 14955 Награды: 14 Регистрация: 20.02.2009 |
Тема открыта для обсуждения.
-------------------- Форум, это место где люди выслушивают аргументы друг друга, а не только высказывают свое мнение. |
 
|
|
10.11.2016, 15:35
Сообщение
#3
|
|
Геймер Репутация: 86 Группа: Участник Сообщений: 128 Награды: 4 Регистрация: 05.05.2012 |
Всем доброго gameru.net! Имеется дилемма, о том, какую СУБД выбрать для проекта. В проекте подразумевается существование функций чата между <n> пользователями. можешь с одинаковым успехом выбрать любую из предложенных субд, потому как для реализации чятика для целых n-человек этот выбор не имеет принципиального значения. Что бы вы могли посоветовать, какой был бы Ваш выбор? смотря какие требования к чатику, документоориентированная субд может стать не лучшим выбором, если история сообщений будет иметь сложную, вложенную структуру, это может привести к тому, что внутри документа появятся целые цепочки одинаковых сообщений, которые придется как-то синхронизировать. -------------------- nop
|
 
|
|
10.11.2016, 16:03
Сообщение
#4
|
|
Геймер Репутация: 86 Группа: Участник Сообщений: 128 Награды: 4 Регистрация: 05.05.2012 |
Собственно, выбор пал на Rethink / Mongo. nosql смысл есть использовать в критичных ко времени выполнения сервисах с большими объемами данных, там где реляцилонная бд не справляется с тяжелыми запросами состоящими из кучи join'ов. чатик явно не относится к этой категории. -------------------- nop
|
 
|
|
10.11.2016, 16:17
Сообщение
#5
|
|
Продвинутый геймер Репутация: 112 Группа: Забанен Сообщений: 499 Награды: 3 Регистрация: 26.12.2009 |
Благодарю за ответ.
Дело в том, что когда писал подобный проект ранее, то была проблема с удалением сообщения. Т.е. простым DELETE * не удалить, ибо удалятся у обоих (такая структура была). Если добавить поле флаг status (0 - удалено у обоих, 1 - у первого, 2 - у второго) потом проблемы с offset возникают -------------------- |
 
|
|
10.11.2016, 16:34
Сообщение
#6
|
|
Геймер Репутация: 86 Группа: Участник Сообщений: 128 Награды: 4 Регистрация: 05.05.2012 |
простым DELETE * не удалить, ибо удалятся у обоих это ошибка проектирования, а не недостаток субд, никто не мешает хранить сообщения пользователей в таблице А, историю сообщений в таблице Б и ссылается на строки таблицы А через внешний ключ. A Код message_id | text ------------------------------- 1 | blablabla ------------------------------- 2 | ololo ------------------------------- 3 | troololo B Код user_id | message_id
------------------------------- 1 | 1 ------------------------------- 1 | 2 ------------------------------- 2 | 1 ------------------------------- 2 | 3 -------------------- nop
|
 
|
|
10.11.2016, 16:36
Сообщение
#7
|
|
Продвинутый геймер Репутация: 112 Группа: Забанен Сообщений: 499 Награды: 3 Регистрация: 26.12.2009 |
простым DELETE * не удалить, ибо удалятся у обоих это ошибка проектирования, а не недостаток субд, никто не мешает хранить сообщения пользователей в таблице А, историю сообщений в таблице Б и ссылается на строки таблицы А через внешний ключ. A Код message_id | text ------------------------------- 1 | blablabla ------------------------------- 2 | ololo ------------------------------- 3 | troololo B Код user_id | message_id ------------------------------- 1 | 1 ------------------------------- 1 | 2 ------------------------------- 2 | 1 ------------------------------- 2 | 3 А с выборкой для чата не будет проблем? Т.е. есть чат между id1, id2 Select * from messages where <dont_know> -------------------- |
 
|
|
10.11.2016, 16:42
Сообщение
#8
|
|
Геймер Репутация: 86 Группа: Участник Сообщений: 128 Награды: 4 Регистрация: 05.05.2012 |
А с выборкой для чата не будет проблем? Т.е. есть чат между id1, id2 заведи в таблице Б идентификатор беседы, тогда запрос будет выглядеть примерно так: Код select text from A join B using (message_id) where chat_id = 1 and user_id = 2 order by message_id;
-------------------- nop
|
 
|
|
10.11.2016, 17:23
Сообщение
#9
|
|
Почти Игрок Репутация: 2 Группа: Участник Сообщений: 20 Награды: 1 Регистрация: 28.01.2015 |
Всем доброго gameru.net!
Имеется дилемма, о том, какой текстовый редактор выбрать для проекта. (фентези книга на 500 страниц и возможности сиквела) В проекте подразумевается существование любовной связи и сюжетной линии между <n> героями. Хранение текста должно быть таким, чтобы при удалении абзаца он не удалялся <n> , а сохранялся на память на всех моих устройствах (Андроид планшет, айфон 4, телефон на ведре, кофемолка с алиэкспресса, фоторамка и умный телевизор LG) для будущих фанатов-пользователей, поэтому я подумал, что сагу лучше хранить в документо-ориентированных бд. Собственно, выбор пал на Блокнот.нет/ Word/ OpenOffice. Что бы вы могли посоветовать, какой был бы Ваш выбор? _____________________________________ для стартапера ты слишком быстрый. уже самоучители по базам данных читаешь, каких-то полгода прошло Сообщение отредактировал Aaye - 10.11.2016, 17:24 |
 
|
|
10.11.2016, 17:32
Сообщение
#10
|
|
Продвинутый геймер Репутация: 112 Группа: Забанен Сообщений: 499 Награды: 3 Регистрация: 26.12.2009 |
А с выборкой для чата не будет проблем? Т.е. есть чат между id1, id2 заведи в таблице Б идентификатор беседы, тогда запрос будет выглядеть примерно так: Код select text from A join B using (message_id) where chat_id = 1 and user_id = 2 order by message_id; Благодарю) -------------------- |
 
|
|
10.11.2016, 19:33
Сообщение
#11
|
|
Gameru DA Репутация: 3704 Группа: Администратор Сообщений: 10206 Награды: 4 Регистрация: 03.02.2006 |
никто не мешает хранить сообщения пользователей в таблице А, историю сообщений в таблице Б и ссылается на строки таблицы А через внешний ключ. 4я нормальная форма, если не ошибаюсь. Medvedkoo, Или -------------------- |
 
|
|
10.11.2016, 20:17
Сообщение
#12
|
|
Высший Игровой Бог Репутация: 1747 Группа: Супермодератор Сообщений: 12594 Награды: 15 Регистрация: 05.11.2009 |
сохранялся на память на всех моих устройствах (Андроид планшет, айфон 4, телефон на ведре, кофемолка с алиэкспресса, фоторамка и умный телевизор LG) SQLite. Или вообще в XML. -------------------- |
 
|
|
10.11.2016, 23:08
Сообщение
#13
|
|
Геймер Репутация: 86 Группа: Участник Сообщений: 128 Награды: 4 Регистрация: 05.05.2012 |
4я нормальная форма, если не ошибаюсь. по мне больше смахивает на нфбк, но я в теории не силен. на практике, будь передо мной такая задача, спроектировал бы нечто подобное: Код create table chat_flags( flag bigint, description character varying (256), constraint chat_flags_pk primary key (flag) ); create table chats( chat_id bigint, title character varying (256), avatar character varying (256), flags bigint, constraint chats_pk primary key (chat_id) ); create table users( user_id bigint, nickname character varying (256), avatar character varying (256), constraint users_pk primary key (user_id) ); create table messages( message_id bigint, user_id bigint, message text, creation_time timestamp without time zone, constraint messages_pk primary key (message_id), constraint messages_fk foreign key (user_id) references users (user_id) ); create table chat_user_messages( chat_id bigint, user_id bigint, message_id bigint, constraint chat_user_messages_pk (chat_id, user_id, message_id), constraint chat_user_messages_fk1 foreign key (chat_id) references chats (chat_id) constraint chat_user_messages_fk2 foreign key (user_id) references users (user_id), constraint chat_user_messages_fk3 foreign key (message_id) references chats (message_id) ); здесь таблица chat_flags описывает дополнительные флаги чата 0 - обычная беседа 2-х пользователей, 1 - беседа 2-х и более пользователей с отдельным названием и аватаром чата. в таблице chats перечислены все существующие беседы, беседы помеченные флагом 1 имеют свой собственный аватар и название. в таблице users перечислены все зарегистрированные пользователи с никами и аватарами. в таблице messages находятся все сообщения пользователей. таблица chat_user_messages объединяет беседы, пользователей и сообщения в составные ключи, по которым можно получить любую информацию о пользователе беседе или сообщении -------------------- nop
|
 
|
|
Текстовая версия | Сейчас: 26.05.2024, 16:39 |