|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
Всем ДВС! Разрабатываются требования к конструктору. Предполагается: 1. Совместный доступ нескольких пользователей к 1 документу 2. Каждый пользователь работает на своем слое (<div>) 3. Каждый пользователь может создавать свои слои внутри назначенного ему слоя То есть в итоге получается следующая картина автор<div class="doc_1"> <div class="user_1"> <div class="user_1_layer_1"> <span id="elem_1" style="color: red;"> </span> <div id="elem_2" style="border: 1px solid gray;"> </div> </div> </div> * * * * * <div class="user_N"> <div class="user_N_layer_1"> <div id="elem_2" style="border: 3px solid #DDD;"> </div> </div> </div> При этом любой пользователь может в любое время изменить например style любого элемента в любом своем слое или удалить любой элемент/слой или добавить новый элемент/слой Подскажите плз, как лучше все это хранить? Заранее благодарен всем за ответы и за конструктивное участие. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2017, 10:59 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
selecterПодскажите плз, как лучше все это хранить? GIT Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2017, 13:27 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
Хотя нет, git неудобен при слиянии. CVS попроще будет. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2017, 13:44 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
Речь идет о клиент-серверном приложении. Формирование набора DIVов происходит визуально в браузере. Чтобы было понятнее - например есть группа детей в детском саду и педагог. Педагог в своем браузере раскладывает разные квадратики (разных цветов и разных размеров) в каком-то порядке. Дети, каждый в своем браузере должен перемещать эти квадратики по своему усмотрению. Могут вращать и т.д. Все это отображается сразу же у педагога и сохраняется ГДЕ-ТО. Реализация предполагается на node.js + koa + socket.io и вопрос стоит где и как хранить. Думалось про MongoDB. Потом перетекло на Postgresql. Теперь думается вообще про файловую систему - то есть хранить все слои отдельно и склеивать готовый файл перед отправкой на клиент. Еще не надо забывать про масштабируемость. Короче башка кругом - как-то не получается в голове уложить все возможные последствия того или иного решения, а посоветоваться не с кем. Вот и прошу помощи у общественности. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2017, 14:12 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
1. Совместный доступ нескольких пользователей к 1 документу 2. Каждый пользователь работает на своем слое (<div>) 3. Каждый пользователь может создавать свои слои внутри назначенного ему слояесть группа детей в детском саду и педагог. Педагог в своем браузере раскладывает разные квадратики (разных цветов и разных размеров) в каком-то порядке. Дети, каждый в своем браузере должен перемещать эти квадратики по своему усмотрению. Могут вращать и т.д. Все это отображается сразу же у педагога и сохраняется ГДЕ-ТО. Два куска описывают разные вещи. Башка трещит, потому что вы сами ещё не поняли, ЧТО вы делаете. Описывайте задачу (человеческими словами) подробней. Как я вижу из ваших слов, то училка рисует исходное задание - набор фигур на канве. Каждое дитятя получает свою копию задания и начинает выплескивать фантазию (крутить, вертеть и т.п.) на этот набор элементов. Для истории, анализа психиатром и просто похвататься перед родителями изыски мелких деток сохраняются в долговременную память. Ваш текущий вопрос состоит в выборе способа сохранения начального задания и детских результатов. Я правильно прочел задание? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2017, 23:39 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
websockets в кач-ве БД чего угодно, но например для геом.фигур постгрес можно, он умеет их хранить ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 11:18 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
AndryG, Вы прочли правильно. Остается только добавить, что каждое законченное действие с фигурой также должно храниться в долговременной памяти. То есть подвинул ребенок красный квадратик в право, и отпустил левую кнопку мыши, координаты квадратика изменились и после фиксации сохранились в долговременной памяти. Потом ребенок передумал и подвинул его еще куда-то. Опять после того как квадратик отпущен - новые координаты сохраняются в долгосрочной памяти. В связи с такими частыми возможными изменениями части документа и возникает сложность в выборе системы долгосрочной памяти. Так что посоветуете? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 15:05 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
selecterТак что посоветуете? Я бы посоветовал использовать стандартную Entity-Relation модель. Нужно хранить каждое действие? Ок, создаём сущность "действие" со всеми необходимыми атрибутами и связями. После выделения всех сущностей доводим модель до третьей нормальной формы как минимум. Потом по логической модели строим физическую, создаём БД, заполняем, начинаем писать приложение. Если при создании запросов возникают проблемы, значит на предыдущих шагах допущена ошибка - возвращаемся, исправляем, повторяем. И так до полного удовлетворения цели. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 15:29 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
Любая реляционная СУБД справится с вашей задачей. Нет ничего сложного в хранении каждого чиха детворы. Для построения структуры БД. Нужно определиться с набором фигур (прямоугольник, круг, прямая) - после этого можно определиться с набором характерных точек для описания фигуры. Нужно определиться с наобором действий (переместить, повернуть, окрасить и т.д.) - это поможет определиться с параметрами действия (новое положение Х, новое положение Y, угол поворота, новый цвет, например) Первая прикидка таблиц: справочник фигур, справочник эскизов, конкретные фигуры эскиза, дети, рисунки детей (потомки/копии эскизов), начальные/новые состояния фигур в детских рисунках. Здесь явно выделяем эскиз препода и рисунок ребенка с набором изменений. При создании нового рисунка из таблицы эскизов копируются начальные положения фигур эскиза. (такое копирование выглядит некрасиво, но решает проблему последующего изменения эскизов) второй вариант Может быть, не стоит разделять эскиз и рисунок. А рассмотривать эскиз, как начальный вариант рисунка и рисунок каждого ребенка наследует его. Тогда можно обойтись без начального копирования. Но надо ли это делать. Тут, в общем, можно голову сушить долго над всякими "а можно". справочник фигур, дети/преподы таблица эскизов/рисунков таблица фигур таблица положения фигур ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 15:49 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
В случае с реляционной БД возникает следующая ситуация. Например речь идет уже не о квадратике,а о пазле из 500 или 1000 элементов. 1 вариант. -------------- Можно взять сущность элемент пазла и его атрибуты например координаты начала и длина и ширина. В случае изменения какого-то атрибута мы апдейтим соответственно в базе. 2 вариант -------------- Мы сохраняем прямо строки канваса в соответствующую таблицу. Потом меняется какой-то атрибут (например координата) и мы можем заменить данную строку целиком. Если потом возникает необходимость загрузить такой документ целиком, то придется делать достаточно затратный запрос, который будет собирать все элементы пазла в один блок. Если взять NoSQL (или JSONB в Postgresql ????) то можно оперировать понятием объект и свойства объекта менять в случае необходимости. А если надо выгрузить весь элемент, то он отдается целиком сразу, а не собирается из отдельных частей. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 17:42 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
автор А если надо выгрузить весь элемент, Прошу прощенья, не ЭЛЕМЕНТ, а ДОКУМЕНТ конечно же ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 17:45 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
selecterЕсли потом возникает необходимость загрузить такой документ целиком, то придется делать достаточно затратный запрос, который будет собирать все элементы пазла в один блок. Ты очень сильно преувеличиваешь затратность этого запроса. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 18:41 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
Поначалу и думал хранить весь рисунок целиком, например, в html/xml. Но вы сказали, что хочется отслеживать изменения каждого элемента. А раз так, то и хранить нужно каждый элемент отдельно. Если занатия в садике проводятся не для тысяч деток одновременнно, то нагрузка на сервер не должна сильно вас беспокоить. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 22:09 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
Вот весь вопрос заключается в том, что детских садиков может быть очень много и тестов тоже не мало. В общем есть требование к скорости отдачи документа и расширяемости БД (горизонтальной масштабируемости) при этом должно соблюдаться отслеживание возможных изменений элементов документа. Если бы это был 1 садик и сотня-другая тестов, я бы даже и не думал - взял бы MySQL или Postgresql Но там сложности с масштабированием. Сложностей с масштабированием нет у MongoDB: и отслеживать каждый элемент документа можно и документ целиком отдать можно, но остаются накладные расходы при конвертации html <---> JSON. Вопрос в скорости поиска и записи. И с NoSQL я никогда не работал, хотя представление имею. Я привык смотреть на максимальные точки. То есть если предположить, исходя из пожеланий заказчика, что данный программный комплекс достигнет масштабов VK или FB, то какую СУБД выбирать при всех вышеуказанных требованиях? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 22:31 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
selecterЯ привык смотреть на максимальные точки. То есть если предположить, исходя из пожеланий заказчика, что данный программный комплекс достигнет масштабов VK или FB, то какую СУБД выбирать при всех вышеуказанных требованиях? Не хочу тебя разочаровывать, но проблема не в СУБД. Тут программист нужен. Такой, у которого и MySQL и PG масштабируются без проблем. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 23:12 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
selecterВот весь вопрос заключается в том, что детских садиков может быть очень много и тестов тоже не мало. В общем есть требование к скорости отдачи документа и расширяемости БД (горизонтальной масштабируемости) Горизонтальная масштабируемость в данном случае достигается элементарно - шардингом (поскольку, как понимаю, совершенно точно Вам никогда не надо будет одним запросом обрабатывать документы разных детсадов). Требования к скорости отдачи документа - ну огласите их тогда. Сколько в среднем элементов в документе и сколько документов в секунду надо отдавать? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 23:17 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
Сам я с шардингом, как и с масштабированием в принципе никогда не сталкивался. Но прочитал http://highload.guide/blog/scaling-what-why-when-and-how.html и понял что в случае с MySQL или Pg все не так уж и сладко. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2017, 23:55 |
|
Выбор способа хранения данных
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovselecterЯ привык смотреть на максимальные точки. То есть если предположить, исходя из пожеланий заказчика, что данный программный комплекс достигнет масштабов VK или FB, то какую СУБД выбирать при всех вышеуказанных требованиях? Не хочу тебя разочаровывать, но проблема не в СУБД. Тут программист нужен. Такой, у которого и MySQL и PG масштабируются без проблем. Знаю я этого "селектера"! "Он" в Химках на вокзале деревянными "монгами" торгует! ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2017, 11:04 |
|
|
start [/forum/topic.php?fid=32&msg=39567039&tid=1540102]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
32ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
others: | 236ms |
total: | 378ms |
0 / 0 |