Всем доброго gameru.net!
Имеется дилемма, о том, какую СУБД выбрать для проекта.
В проекте подразумевается существование функций чата между <n> пользователями.
Хранение сообщений должно быть таким, чтобы при удалении сообщения у пользователя <n> i-ого, сообщения сохранялись у остальных пользователей, поэтому я подумал, что сообщения лучше хранить в документо-ориентированных бд.
Собственно, выбор пал на Rethink / Mongo.
Что бы вы могли посоветовать, какой был бы Ваш выбор?
Полная версия этой страницы: Выбор СУБД для проекта
Тема открыта для обсуждения.
Цитата(Medvedkoo @ 10.11.2016, 01:06) 
Всем доброго gameru.net!
Имеется дилемма, о том, какую СУБД выбрать для проекта.
В проекте подразумевается существование функций чата между <n> пользователями.
Имеется дилемма, о том, какую СУБД выбрать для проекта.
В проекте подразумевается существование функций чата между <n> пользователями.
можешь с одинаковым успехом выбрать любую из предложенных субд, потому как для реализации чятика для целых n-человек этот выбор не имеет принципиального значения.
Цитата(Medvedkoo @ 10.11.2016, 01:06)
Что бы вы могли посоветовать, какой был бы Ваш выбор?
смотря какие требования к чатику, документоориентированная субд может стать не лучшим выбором, если история сообщений будет иметь сложную, вложенную структуру, это может привести к тому, что внутри документа появятся целые цепочки одинаковых сообщений, которые придется как-то синхронизировать.
Цитата(Medvedkoo @ 10.11.2016, 01:06)
Собственно, выбор пал на Rethink / Mongo.
nosql смысл есть использовать в критичных ко времени выполнения сервисах с большими объемами данных, там где реляцилонная бд не справляется с тяжелыми запросами состоящими из кучи join'ов. чатик явно не относится к этой категории.
Благодарю за ответ.
Дело в том, что когда писал подобный проект ранее, то была проблема с удалением сообщения. Т.е. простым DELETE * не удалить, ибо удалятся у обоих (такая структура была). Если добавить поле флаг status (0 - удалено у обоих, 1 - у первого, 2 - у второго) потом проблемы с offset возникают
Дело в том, что когда писал подобный проект ранее, то была проблема с удалением сообщения. Т.е. простым DELETE * не удалить, ибо удалятся у обоих (такая структура была). Если добавить поле флаг status (0 - удалено у обоих, 1 - у первого, 2 - у второго) потом проблемы с offset возникают
Цитата(Medvedkoo @ 10.11.2016, 18:15)
простым DELETE * не удалить, ибо удалятся у обоих
это ошибка проектирования, а не недостаток субд, никто не мешает хранить сообщения пользователей в таблице А, историю сообщений в таблице Б и ссылается на строки таблицы А через внешний ключ.
A
Код
message_id | text
-------------------------------
1 | blablabla
-------------------------------
2 | ololo
-------------------------------
3 | troololo
-------------------------------
1 | blablabla
-------------------------------
2 | ololo
-------------------------------
3 | troololo
B
Код
user_id | message_id
-------------------------------
1 | 1
-------------------------------
1 | 2
-------------------------------
2 | 1
-------------------------------
2 | 3
-------------------------------
1 | 1
-------------------------------
1 | 2
-------------------------------
2 | 1
-------------------------------
2 | 3
Цитата(refuse @ 10.11.2016, 17:32)
Цитата(Medvedkoo @ 10.11.2016, 18:15)
простым DELETE * не удалить, ибо удалятся у обоих
это ошибка проектирования, а не недостаток субд, никто не мешает хранить сообщения пользователей в таблице А, историю сообщений в таблице Б и ссылается на строки таблицы А через внешний ключ.
A
Код
message_id | text
-------------------------------
1 | blablabla
-------------------------------
2 | ololo
-------------------------------
3 | troololo
-------------------------------
1 | blablabla
-------------------------------
2 | ololo
-------------------------------
3 | troololo
B
Код
user_id | message_id
-------------------------------
1 | 1
-------------------------------
1 | 2
-------------------------------
2 | 1
-------------------------------
2 | 3
-------------------------------
1 | 1
-------------------------------
1 | 2
-------------------------------
2 | 1
-------------------------------
2 | 3
А с выборкой для чата не будет проблем?
Т.е. есть чат между id1, id2
Select * from messages where <dont_know>
Цитата(Medvedkoo @ 10.11.2016, 18:34)
А с выборкой для чата не будет проблем?
Т.е. есть чат между id1, id2
Т.е. есть чат между id1, id2
заведи в таблице Б идентификатор беседы, тогда запрос будет выглядеть примерно так:
Код
select text from A join B using (message_id) where chat_id = 1 and user_id = 2 order by message_id;
Всем доброго gameru.net!
Имеется дилемма, о том, какой текстовый редактор выбрать для проекта. (фентези книга на 500 страниц и возможности сиквела)
В проекте подразумевается существование любовной связи и сюжетной линии между <n> героями.
Хранение текста должно быть таким, чтобы при удалении абзаца он не удалялся <n> , а сохранялся на память на всех моих устройствах (Андроид планшет, айфон 4, телефон на ведре, кофемолка с алиэкспресса, фоторамка и умный телевизор LG) для будущих фанатов-пользователей, поэтому я подумал, что сагу лучше хранить в документо-ориентированных бд.
Собственно, выбор пал на Блокнот.нет/ Word/ OpenOffice.
Что бы вы могли посоветовать, какой был бы Ваш выбор?
_____________________________________
для стартапера ты слишком быстрый. уже самоучители по базам данных читаешь, каких-то полгода прошло
Имеется дилемма, о том, какой текстовый редактор выбрать для проекта. (фентези книга на 500 страниц и возможности сиквела)
В проекте подразумевается существование любовной связи и сюжетной линии между <n> героями.
Хранение текста должно быть таким, чтобы при удалении абзаца он не удалялся <n> , а сохранялся на память на всех моих устройствах (Андроид планшет, айфон 4, телефон на ведре, кофемолка с алиэкспресса, фоторамка и умный телевизор LG) для будущих фанатов-пользователей, поэтому я подумал, что сагу лучше хранить в документо-ориентированных бд.
Собственно, выбор пал на Блокнот.нет/ Word/ OpenOffice.
Что бы вы могли посоветовать, какой был бы Ваш выбор?
_____________________________________
для стартапера ты слишком быстрый. уже самоучители по базам данных читаешь, каких-то полгода прошло
Цитата(refuse @ 10.11.2016, 17:40)
Цитата(Medvedkoo @ 10.11.2016, 18:34)
А с выборкой для чата не будет проблем?
Т.е. есть чат между id1, id2
Т.е. есть чат между id1, id2
заведи в таблице Б идентификатор беседы, тогда запрос будет выглядеть примерно так:
Код
select text from A join B using (message_id) where chat_id = 1 and user_id = 2 order by message_id;
Благодарю)
Цитата(refuse @ 10.11.2016, 15:32)
никто не мешает хранить сообщения пользователей в таблице А, историю сообщений в таблице Б и ссылается на строки таблицы А через внешний ключ.
4я нормальная форма, если не ошибаюсь.
Medvedkoo,
Или
Цитата(Aaye @ 10.11.2016, 17:21)
сохранялся на память на всех моих устройствах (Андроид планшет, айфон 4, телефон на ведре, кофемолка с алиэкспресса, фоторамка и умный телевизор LG)
SQLite. Или вообще в XML.
Цитата(OlegatoR @ 10.11.2016, 21:31)
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)
);
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 объединяет беседы, пользователей и сообщения в составные ключи, по которым можно получить любую информацию о пользователе беседе или сообщении
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.