Предположим, мы имеем хранилище ("база данных") любых сущностей ("объекты"). Ну, т.е. в нём можно сохранить любую (ну или почти любую) информацию. Причём не просто сохранить, а предварительно создав описания ("классы") для каждого типа сущностей.
Например, для внесения в хранилище сущности-сообщения "привет", в нём предварительно создаём описание:
тип — "сообщение"
текст — string
автор — string
и после создаём само сообщение, где "текст" — "привет", "автор" — "кто-то", а тип берётся из описания как есть. Получается что-то типа следующего:
сообщение: "привет", "кто-то"
Жёсткой структуры хранения нет — где пользователь создал сущность, там она и хранится. Но при этом есть "рабочие области" (только в них можно создавать сущности) и возможно организовывать деревья (любая сущность может быть родителем других сущностей).
Просто так хранить сущности не интересно, поэтому над ними доступны стандартные действия: описанное выше создание, а также редактирование и удаление. Это — стандартные простые действия, т.к. управляют только одной сущностью без дополнительных параметров. Даже если в сущности содержится ссылка на другую сущность (например предположим, что в примере выше, "автор" указывается как ссылка на другую сущность "Иванов Иван") — это всё равно действие над одной сущностью.
А теперь к проблемам.
Я хочу добавить более сложные действия над сущностями, когда вместе с действием указываются дополнительные параметры или ссылки на другие сущности.
Например:
Во-первых, получается, что в хранилище нужно сохранять уже не одну сущность, а действие в связке со всеми задействованными в нём сущностями. Т.е. получается, что хранилище должно хранить не только сущности, но и действия. Если предыдущий пример Вас в этом не убедил, вот другой:
Сохраняя это действие в хранилище — мы также сохраняем права доступа к хранилищу, а это нужная информация.
Почему это именно действие, а не сущность — не уверен, что могу объяснить. Может потому, что нет возможности точно определиться, какую сущность в какой хранить: пользователя в рабочей области или рабочую область в пользователе.
Отдельное от объектов хранение действий позволяет, во-первых, вводить команды в любой последовательности операндов, а во-вторых, что очень важно, можно к любому хранящемуся объекту применить действие, которое использует в качестве операнда тип данного объекта.
А теперь, для тех кто дочитал до сюда, правильно ли я думаю: если у нас есть две сущности, хранящиеся в разных местах, то сохранять действие, которое использовало эти сущности, нужно:
1. там, где действие выполнено;
2. там, где хранятся сущности (это актуально для примера с правами доступа — надо обязательно сохранить в рабочей области);
3. предоставлять автору действия выбирать, где сохранять действие.
R3>1. ...там, где действие выполнено; R3>2. там, где хранятся сущности (это актуально для примера с правами доступа — надо обязательно сохранить в рабочей области); R3>3. предоставлять автору действия выбирать, где сохранять действие...
Аналогично, разбирая бизнес-процессы, я пришел к выводу, что неудобно выстраивать все сущности в один длинный список и затем строить между ними связи — процессы. Действительно, не всегда понятно к какой сущности больше привязан тот или иной процесс.
Но система выстроилась, когда я рассмотрел двумерное пространство (уже рассматриваю трехмерное), т.е. разбил группы сущностей на пространства и стал рассматривать связи в пространстве, а не на одной оси.
Теперь понимаю, что, например, википедия — это большой хаос статей, который невозможно выстроить в один большой список по областям, необходимо рассматривать несколько подпространств, каждую статью (абзац статьи) относить по координатам в многомерном пространстве.
Здравствуйте, sereginseregin, Вы писали:
S>Аналогично, разбирая бизнес-процессы, я пришел к выводу, что неудобно выстраивать все сущности в один длинный список и затем строить между ними связи — процессы. Действительно, не всегда понятно к какой сущности больше привязан тот или иной процесс.
Ну, такого вопроса у меня не стоит: сущность либо используется в действие (в твоём случае — в БП), либо нет.
S>Но система выстроилась, когда я рассмотрел двумерное пространство (уже рассматриваю трехмерное), т.е. разбил группы сущностей на пространства и стал рассматривать связи в пространстве, а не на одной оси. S>Теперь понимаю, что, например, википедия — это большой хаос статей, который невозможно выстроить в один большой список по областям, необходимо рассматривать несколько подпространств, каждую статью (абзац статьи) относить по координатам в многомерном пространстве.
Я думаю, что действия над сущностями, нужно хранить в том месте где хранится описание сущностей. Можно использовать для группировки что то типа пространства имен. Вообще нужно исходить от необходимого api к хранилищу.
R3>Сохраняя это действие в хранилище — мы также сохраняем права доступа к хранилищу, а это нужная информация. R3>Почему это именно действие, а не сущность — не уверен, что могу объяснить. Может потому, что нет возможности точно определиться, какую сущность в какой хранить: пользователя в рабочей области или рабочую область в пользователе. R3>Отдельное от объектов хранение действий позволяет, во-первых, вводить команды в любой последовательности операндов, а во-вторых, что очень важно, можно к любому хранящемуся объекту применить действие, которое использует в качестве операнда тип данного объекта.
Пришёл к следующим мыслям.
Если у нас есть такое действие, как в примере, то из него следует, что спрашивая у системы "какие пользователи имеют доступ к 'ТакойТо' рабочей области" и "в какие рабочие области имеет доступ 'ТакойТо' пользователь", получаем, что действие надо хранить так, чтобы оно было доступно как совместно с каждой рабочей областью, так и с каждым пользователем. Причём при изменении действия в одном месте, оно должно сразу измениться в другом.
Следовательно, действие должно быть одно и при этом быть чем-то типа связи двух сущностей.
Сейчас думаю, сохранять действия в хранилище, но не в явном виде, как сущности, а отображать их по конкретному запросу пользователя.
Здравствуйте, Real 3L0, Вы писали:
R3>Пришёл к следующим мыслям...
Давно пора было прийти к мыслям, что хранение зависит от тех запросов, которые ты собрался делать.
Перед тем, как описывать хранение — опиши какие запросы будут поступать к твоей системе.
Здравствуйте, gandjustas, Вы писали:
G>Давно пора было прийти к мыслям, что хранение зависит от тех запросов, которые ты собрался делать. G>Перед тем, как описывать хранение — опиши какие запросы будут поступать к твоей системе.
В названии темы — любые. А другой стороны я не понял, какие ещё бывают запросы, кроме как получить данные, изменить и удалить?
Здравствуйте, Real 3L0, Вы писали: R3>В названии темы — любые. А другой стороны я не понял, какие ещё бывают запросы, кроме как получить данные, изменить и удалить?
Ок, характерные примеры запросов в реальных информационных системах:
1. Вывести список вариантов авиаперелёта из Новосибирска в Мехико и обратно, прилёт не позже 10:00 утра понедельника по местному, отлёт не раньше 20:00 пятницы по местному, отсортированных по возрастанию стоимости.
2. Перевести 600 рублей со счёта 4010.............22 на оплату мобильного номера +7 9........5
3. Показать 10 топиков форума с максимальной активностью за последние 48 часов
Несмотря на то, что каждый из них можно выразить в терминах запросов "получить список ID всех объектов типа А" + "получить детали объекта по его ID" + "сохранить изменения в объект по его ID", эффективность такой реализации будет сосать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Несмотря на то, что каждый из них можно выразить в терминах запросов "получить список ID всех объектов типа А" + "получить детали объекта по его ID" + "сохранить изменения в объект по его ID", эффективность такой реализации будет сосать.
Дело в том, что у меня проблема не в реализации, а в постановке задачи, в аналитике. И в добавок хотелось бы понять, как это может выглядеть интерфейсно.
А реализация — дело наживное.
За примеры спасибо.
Здравствуйте, Real 3L0, Вы писали:
R3>Дело в том, что у меня проблема не в реализации, а в постановке задачи, в аналитике.
Ну так это оттого, что у вас постановки нет. Задача "вычислять неизвестно что неизвестно как" имеет много классических решений. Например — машина Тьюринга.
Если вы хотите построить более удобное решение, то придётся сузить задачу. R3>И в добавок хотелось бы понять, как это может выглядеть интерфейсно.
Сначала надо понять, что такое "это". Вы сейчас пытаетесь уловить сходство, а уж потом рисовать портрет (с).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну так это оттого, что у вас постановки нет. Задача "вычислять неизвестно что неизвестно как" имеет много классических решений. Например — машина Тьюринга. S>Если вы хотите построить более удобное решение, то придётся сузить задачу.
Задача проста: хочу некую систему, куда я
1. могу заносить информацию (в идеале — любую)
2. управлять этой информацией (в иделе — любое управление)
Если допустить, что эта система уже создана, то пример использования: создал контакт (человека), написал ему письмо, поставил ему задачу, импортировал картинку, уменьшил размеры картинки, ну и два первых твоих примера (про самолёт и перевод денег; необходимость в третьем пока не вижу). И т.п. — как минимум, все "тупые" операции, выполняемые на компьютере.
Здравствуйте, Real 3L0, Вы писали:
R3>Задача проста: хочу некую систему, куда я R3>1. могу заносить информацию (в идеале — любую) R3>2. управлять этой информацией (в иделе — любое управление)
Вашим требованиям с избытком удовлетворяет файловая система FAT-12.
R3>Если допустить, что эта система уже создана, то пример использования: создал контакт (человека), написал ему письмо, поставил ему задачу, импортировал картинку, уменьшил размеры картинки, ну и два первых твоих примера (про самолёт и перевод денег; необходимость в третьем пока не вижу). И т.п. — как минимум, все "тупые" операции, выполняемые на компьютере.
Все тупые операции и так выполняются на компьютере.
Задачи по-прежнему нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вашим требованиям с избытком удовлетворяет файловая система FAT-12.
Да, если в ФАТ включим и командную строку тоже. Но, во-первых, очень хочется "юзерфрендли".
S>Все тупые операции и так выполняются на компьютере.
И во-вторых, ещё хочется с помощью единого интерфейса (в какой-то степени это следует из "юзерфрендли", т.к. отсутствует необходимость изучения новых интерфейсов).
S>Задачи по-прежнему нет.
А сейчас?
...
P.S. Голосовое управление не предлагать в связи с отсутствием 100% распознавания.
Здравствуйте, Real 3L0, Вы писали:
R3>Да, если в ФАТ включим и командную строку тоже. Но, во-первых, очень хочется "юзерфрендли".
Критериев юзерфрендливости не озвучено.
S>>Все тупые операции и так выполняются на компьютере. R3>И во-вторых, ещё хочется с помощью единого интерфейса (в какой-то степени это следует из "юзерфрендли", т.к. отсутствует необходимость изучения новых интерфейсов).
command.com даёт вполне себе единый интерфейс.
S>>Задачи по-прежнему нет. R3>А сейчас?
И сейчас нет.
R3>P.S. Голосовое управление не предлагать в связи с отсутствием 100% распознавания.
Даже если бы было 100% распознавание с детектом подтекстов и сарказмов, это бы не помогло. Проблема не в распознавании, а в отсутствии постановки задачи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair, упомянул про коммандную строку. Как-то я забыл про неё, хотя когда-то думал о ней.
Т.е. получается, что действие — это множество пар [<параметр> <значение>] + [название действия]
Таким образом, действие можно записать как сущность:
Здравствуйте, Sinclair, Вы писали:
R3>>Да, если в ФАТ включим и командную строку тоже. Но, во-первых, очень хочется "юзерфрендли". S>Критериев юзерфрендливости не озвучено.
Например, у командной строки нет "понятности", т.е. часто из названия команды не понятно, что она делает (а есть ещё ключи).
S>command.com даёт вполне себе единый интерфейс.
Здравствуйте, Real 3L0, Вы писали:
R3>Например, у командной строки нет "понятности", т.е. часто из названия команды не понятно, что она делает (а есть ещё ключи).
Ну, тогда попробуйте Windows Explorer — он же дефолтный шелл пользовательских версий винды.
R3>Упростить/облегчить взаимодействие с компьютером.
Это не задача. Как только у вас в требованиях появляются сравнительные степени (легче, проще, быстрее), надо сразу задавать
а) по сравнению с чем и
б) на каких сценариях
Потому что, скажем, заменить во всех файлах в определённом пути символ "," на ", ёпть," из командной строки линукса значительно быстрее/легче/проще, чем в GUI Windows Explorer.
При этом напомню, что пользователь "систему хранения данных" не видит вообще. Он видит исключительно UI — и можно сделать офигенно удобный UI на чистой файлухе (т.е. древовидное хранение именованных блобов), а можно сделать полное угробище поверх пост-реляционной ОО СУБД с транзакциями и шлюхами.
Вы в какой области хотите задачу решить — User Experience или Back-end?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Real 3L0, Вы писали: R3>Т.е. получается, что действие — это множество пар [<параметр> <значение>] + [название действия] R3>Таким образом, действие можно записать как сущность:
(headbang).
Записываемость действия как сущности вообще никак не зависит от UI — будь там командная строка или веб-интерфейс.
Вот у вас есть "объект" контакт, который состоит из нескольких скалярных атрибутов и ссылок типа "начальник/подчинённый".
Чем этот объект отличается от объекта "изменить контакт", с атрибутами типа "дата изменения", "инициатор", "список троек "имя свойства, значение до, значение после""?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
R3>>Например, у командной строки нет "понятности", т.е. часто из названия команды не понятно, что она делает (а есть ещё ключи). S>Ну, тогда попробуйте Windows Explorer — он же дефолтный шелл пользовательских версий винды.
У него (в отличии от command.com) нет возможности выполнить любое действие.
R3>>Упростить/облегчить взаимодействие с компьютером. S>Это не задача. Как только у вас в требованиях появляются сравнительные степени (легче, проще, быстрее), надо сразу задавать S>а) по сравнению с чем и S>б) на каких сценариях
+1.
а) по сравнению с текущим программным обеспечением (например, с тем же command.com)
б) на максимально возможных (согласен, расплывчато, но это моя цель)
S>Потому что, скажем, заменить во всех файлах в определённом пути символ "," на ", ёпть," из командной строки линукса значительно быстрее/легче/проще, чем в GUI Windows Explorer.
Это если файлов много, а если один — эксплорер рулит. Более того, эксплорер рулит при количестве не больше N замен, где N — индивидуально. Например, я не помню какая команда отвечает за переименование, но помню стандартную клавишу F2 (переименование) + знаю о copy-paste, поэтому при некотором N мне проще сделать ручками, чем вспоминать (искать) название команды и какие у неё операнды.
И эта ситуация актуальна для всех редких действий.
Это, кстати, хороший пример юзерфрендли.
S>При этом напомню, что пользователь "систему хранения данных" не видит вообще. Он видит исключительно UI — и можно сделать офигенно удобный UI на чистой файлухе (т.е. древовидное хранение именованных блобов), а можно сделать полное угробище поверх пост-реляционной ОО СУБД с транзакциями и шлюхами.
+1.
S>Вы в какой области хотите задачу решить — User Experience или Back-end?
Думаю, в первой, т.к. проблемы пока только в ней, а вторая у меня всегда зависила от первой.
А другой стороны я не понял, какие ещё бывают запросы, кроме как получить данные, изменить и удалить?
