Доброго дня, форумчане.
У меня очередной рецидив программирования, пробую написать оболочку для личной базы знаний. Опять пытаюсь научится готовить отношения многие-ко-многим (МкМ), со структурой таблиц хочется реализовать одну таблицу для хранения сущностей, и вторая таблица, где будут храниться вершины графа попарно, плюс код отношения меду ними. То есть строки из первой таблицы будут соединяться между собой посредством пары кодов в строке второй.

Но вот дальше не могу придумать интерфейс для добавления, редактирования, просмотра этого дела, чтоб при этом шевелилось быстро и не глючило. Какие контролы использовать, поначалу думал сделать в одном гриде вложенные комбо: первая сущность, отношение, вторая сущность, ну и дата создания отношения, потом редактирование через выбор из всплывающей формы. Но уже не уверен что будет юзабильно, да и плоское восприятие в таблице.. Может кто уже думал над чем-то подобным, поделитесь.

Много-ко-многим IMHO лучше визуализировать как 1-ко-многим, т.е. грубо говоря ставить фильтр с той или иной стороны, и показывать "за раз" только связи к одной сущности. Когда они сразу все в списке - получается неудобоваримая каша.
Править - ну сильно от объёма ввода (именно "связей") зависит. Если это не основное время работы юзера (т.е. он не очень часто создаёт связи) то лучше в отдельной простой форме реализовать - возможно одновременно с созданием самих сущностей (если их список достаточно динамичен) - т.е. тут же и создал и "привязал".
Если же это основа программы... Ну тогда надо изобретать варианты.
Скажем если сами списки "связываемых" не очень велики (хотя бы один из них не превышает пары десятков элементов, или всегда можно применить такой фильтр который сведёт один список к 10-20 элементам) то можно чеклистом сделать - т.е. "список с чекбоксами", которыми и "включать" одно в другое - т.е. создавать эту самую связь.
Хотя если у тебя не просто связь, а ещё и "связь с типом связи" - там уже не обойтись простыми вариантами... Ну если не делать для каждого "типа связи" свой отдельный интерфейс (конечно класс/форма то там может одна и та же быть - но просто визуально один экземпляр такой формы задаёт лишь ОДИН "тип связи"). Просто когда к id1,id2 добавляется ещё хоть один значимый реквизит (не считая какого служебного link_id autoinc) - хоть "тип связи", хоть "дата связывания" - это УЖЕ будет не схема с 2-мя сущностями и связью м-м между ними, а схема с 3-мя полноценными сущностями, и 2-мя связями 1-м.
То что "основные" твои сущности хранятся в одной таблице не имеет в данном случае значения, если их можно однозначно разделить на "правую" и "левую" половины.

Если же речь именно про равноправные сущности и связи задающие настоящий граф - ну это уже не совсем реляционная модель данных. И не факт что её вообще можно адекватно разруливать через "табличную" форму представления. м.б. надо какую "карту местности" рисовать, или ещё как визуализировать именно граф.
В общем если бы была более конкретная постановка задачи, было бы проще хоть что-то кроме "общих слов" сказать

Понимаю, что совсем не реляционная модель данных, но процессоры у нас тоже универсальные, а мы на них нейросети сети пытаемся делать.
Как говориться, кушаем что есть, с другими языками еще нет такого опыта работы с данными, python копаю понемногу, но это перспектива, а в информации порядок хочется начать наводить сейчас. Все что вижу, а`ля Evernote - не хватает деревянной иерархии даже при наличии тэгов.
Вики ближе, но делать страничку на каждый атрибут... и опять это смотреть а не оперировать.
Так что надеюсь на быстроту Фокса, может вывезет мой велосипед.

Типов связи, думаю, будет порядка 100-200
- Отношения вроде: Включает, Содержится в, Необходимо для, Требует
- и тип информации: сайт, телефон, почта, серийный, номер, цена

А вот сущности могут быть в обеих половинах

Комп - Содержит - HDD - ( дата когда утановил)
HDD - Имеет - серийный номер
HDD - Имеет - Бренд
HDD - Имеет - Емкость

а вот как цепочке HDD - Имеет - серийный номер - имеет -Цена (Контрагент)

Получается еще надо разделять на Классы (HDD)
и Экземпляры имеющие атрибуты (сер.номер, цена , поставщик, состояние) и хранить их значения. Вобщем, скрестить ежа с ужом , надо еще складской учет впихнуть ))

Конечно, неплохо бы визуализацию типа Personal Brain
но это потом, на пенсии если сил и времени будет.
или сын подрастет, доделает ))

1. А-а-а, попытка а-ля 1С, тут двумя таблицами не отделаешься.

2. Вместо комбо в гриде можно использовать Container + TextBox + CommandButton, правда вся эта байда в гриде начинает подторимаживать во время отрисовки при 25-30 записях и тормозить при 50.

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

Вот задумался о динамическом создании объектов на форме, для наглядного отображения - веселиться так по полной )

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

Грид - Контейнер в нём текстбокс и кнопка, в текстбоксе отображаешь смысл записи, по кноке открываешь формы выбора-редактировани итд. В чём трудность не понял?

frontman
Вот задумался о динамическом создании объектов на форме, для наглядного отображения - веселиться так по полной )

Дин. объекты на форме - это те же тормоза, только проявятся они при 100-200 объектов.

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

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

Сущность Отношения Сущность

а внизу, по задержке после перемещения дорисовать диаграмму для текущего объекта из 1 или 3 грида

Нужно придумать как-то группировать по ревалентности к предметным областям,
чтобы не листать сотни сущностный . Список больше 30 десятков уже плохо воспринимается навскидку

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

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

Сущность Отношения Сущность

а внизу, по задержке после перемещения дорисовать диаграмму для текущего объекта из 1 или 3 грида

Ну, накидай в Form дизайнере картинку и выложи сюда.

frontman
Нужно придумать как-то группировать по ревалентности к предметным областям,
чтобы не листать сотни сущностный . Список больше 30 десятков уже плохо воспринимается навскидку

Зачем листать, делаешь форму поиска сущности-атрибута, по like или точному соответствию (это как надо) получишь ограниченный список.

Тут таблички, какими они были 6 лет назад и картинка фильтра 12 лет назад... (без слёз не взглянешь)

frontman
Нужно придумать как-то группировать по ревалентности к предметным областям,
чтобы не листать сотни сущностный . Список больше 30 десятков уже плохо воспринимается навскидку

Зачем листать, делаешь форму поиска сущности-атрибута, по like или точному соответствию (это как надо) получишь ограниченный список.

Тут таблички, какими они были 6 лет назад и картинка фильтра 12 лет назад... (без слёз не взглянешь)

Мега-универсальную "объектную структуру" с использованием 3-4 таблиц лет 15 назад делали в проекте FoxServer (проект не взлетел, если что) - я кратенько с докой в своё время знакомился...
Это примерно вот такая фиговина как описано тут: compress.ru
Похожий подход (хотя и не настолько экстремистско-"универсальный") применяется в БД для ErWin (раньше он назывался ModelMart, как сейчас не скажу) - и при более-менее приличной по размеру модели - скажем с тысячу "объектов" и 20-30 тысяч их "свойств" всё это ворочается весьма неторопливо...

Лично я сейчас считаю что в "чистом виде" такая схема в принципе не взлетит (можно поискать критику подхода для основной аргументации "почему"). А наделав кучу костылей поддерживающих хоть минимально приемлемую скорость работы мы потеряем главный плюс этой штуки - простоту и универсальность.

В общем просто посоветую - не занимайся этим - пустая трата времени Если не устраивает реляционная модель, то:
1) не используй фокс.
2) не использую реляционную СУБД для "эмуляции" хоть объектной, хоть иерархической или сетевой структуры данных.

И да, вопрос юзер-интерфейса в данном случае не то что не "первый", он вообще далеко не "в десятке" вопросов которые тебе придётся решать

Я согласен, что суп неудобно вилкой есть, но если кушать хочется..

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

Летали же на первых пнях поиски с миллионами записей, и здесь пусть на костылях, но для себя удобно сделаю, а то устал по десяткам програм прыгать - в одной учет финансов, в другой списки задач, в третьей пароли.. и еще куча инфы теряется т.к уже забываю. Старческая деменция уже не за горами, надо костыли себе готовить. Кстати, решение нестандартных задач один из лучших методов профилактики )



Исправлено 2 раз(а). Последнее : frontman, 10.10.18 09:37

И интерфейс, Игорь, архиважная штука. Потому как на переключение между разными задачами, уровнями и предметными областями лично у меня уходит слишком много времени. Тут, конечно, еще и моя личная неорганизованность,
но я мечтаю о личной информационной системе для всего, от менеджмента фоток до инвентаризации вещей и сроков хранения продуктов.
Разработать систему и при этом чтоб особо не напрягала и все было под рукой. Вот тут у меня проблема, мне очень трудно представить себе удобный и эффективный интерфейс для даже многоуровневого списка взаимосвязанных задач, тут даже дерево не спасает, скорее облако тэгов.
Конечно, придется потом переходить на web, Qt + Python, но пока разработаю что-то для сбора и поиска данных, может потом свой FoxServer получится )

Получение данных тоже, по возможности, автоматизируется
Здорово помогают, например Q коды в чеках, учет и анализ покупок стал много легче. Пользуюсь неплохой прогой win + Androud, тут планирую выгрузку данных сделать для расширения функционала, программирование под Андроид освоить быстро вряд ли выйдет, но в мечтах тоже есть.

Ресурс времени ограничен...

Вот я и пытаюсь сделать инструмент для организации времени и информации,
так как только для финансов смог что-то подобрать, а для управления задачами и информацией пытаюсь, но не получается. Даже удовлетворяющего каталогизатора для файлов, электронных книг - не подобрал.
Пробовал Evernote, Nimbus, TaskCoach, Wunderlist.. да много чего.
Как только пытаешься использовать чуть шире - становится не видно леса за деревьями.. Ну это мои тараканы все вести к крайностям, поэтому и велосипед будет для себя.
Времени, да, катастрофически нет, а то бы взялся писать операционную систему, где были бы встроенные возможности БД )))
Много вариантов, кстати, организации на основе файловой системы, но это опять очень локальный вариант



Исправлено 1 раз(а). Последнее : frontman, 10.10.18 12:31

frontman
Времени, да, катастрофически нет

Песочные часы неумолимы... Стоит ли игра свеч?..

frontman
Главная фишка фокса скорость работы с данными, для локального личного использования ничего лучше не вижу, поэтому придется натягивать ежа на глобус.

Подобная "универсальная схема" с лёгкостью убъёт что фокс, что любую другую "солидную" РСУБД.
Сильный отход от "подразумеваемого способа использования" всегда к этому и приводит.

Отношение МкоМн фактически разбивается на два ОкоМн. Ну будет в цепочке несколько таких связок, но переход по ним будет последовательным. Без реализации графического представления(что потом можно сделать внешними средствами) никакого нарушения парадигмы не вижу. Где по вашему капля никотина?

Да, уже сам понял. Придется всю цепочку для идентификации объекта как-то собирать или хранить.
Тогда придется использовать таблицу, где в строке каждый уровень цепочки через связь:

код сущности - код связи - код сущности - код связи - код сущности...

а атрибуты цеплять по составному индексу из этих кодов



Исправлено 3 раз(а). Последнее : frontman, 11.10.18 10:48