[morebeauty]

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

Суть:
Универсальная база данных для всех (или почти всех) задач. По своей организации похожа на файловую систему.

Сама база состоит из нескольких таблиц
1. Таблица с объектами (файлы или папки)
Состоит из ID, Имени объекта, типа объекта (папка/файл/корень), содержимое (перечислен список дочерних объектов, которые находятся непосредственно внутри текущего)
2. Таблица со свойствами объектов (атрибутов)
ID, ID объекта, тип свойства (строка/картинка/иконка) Имя свойства, столбцы значений в зависимости от типа.

3. Таблица справочник типов (таких таблиц несколько, например одна для справочника типов объектов)
4. Таблица с содержимым
ID, ID объекта, тип содержимого, далее поля в зависимости от типа содержимого (текстовое (МЕМО), картинка, строка)... можно обойтись одним или добавить еще при желании.


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

Методами класса должно быть можно считать содержимое объекта, дочерние объекты, свойства (атрибуты) объекта.

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

Нужно, например, вам сделать программу для учета инвентарных единиц. Там будут категории единиц (мебель, ПК (а тут есть и подкатегории), стредства гигиены) и сами единицы (файлы в модели, или один файл со списком единиц).
Или у вас есть еще телефонный справочник организации. Можно хранить его базу все в той же базе, создав папки для каждой вашей программы.


Кроме класса с методами для использования должна быть еще программа для администрирования базы данных, которая отобразит базу в виде дерева каталогов (как ShellTreeView) и позволит смотреть и изменять их содержимое и атрибуты, а так же содержимое файлов. Так же которая позволит делать самостоятельные бэкапы нужных категорий (каталогов) и восстанавливать их.


Плюсы такой модели:
Гибкость.
Простота использования.
Не требует от программиста умения работать с базами данных.

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

[M.A.D.M.A.N.]

Нихрена не понял, на кой оно нужно?

[morebeauty]

Нужно это для того же, для чего программеры ушли от машинных кодов к языкам высокого уровня. А именно для упрощения работы.

Так же для упрощения администрирования базы.

[Aristarh Dark]

MS Access?????

[morebeauty]

Желательно для MSSQL.

[poli-smen]

Сообщение от morebeauty

Сама база состоит из нескольких таблиц
1. Таблица с объектами (файлы или папки)
Состоит из ID, Имени объекта, типа объекта (папка/файл/корень), содержимое (перечислен список дочерних объектов, которые находятся непосредственно внутри текущего)

А в каком виде здесь представлено "содержимое"?

[morebeauty]

Сообщение от poli-smen

А в каком виде здесь представлено "содержимое"?

Не совсем понял вопроса, но приведу пару столбцов для примера на всякий случай

ID / Имя объекта / Тип объекта / содержит объекты (перечисление ИД)
1 / root / root / (2)(3)
2 / Catalog1 / Catalog / (5)
3 / Catalog2 / Catalog / (4)(6)
4 / Catalog3 / Catalog / (7)
5 / File1 / File / Null
6 / File2 / File / Null
7 / File3 / File / Null

И означать это будет, что база содержит 3 файла:
root/Catalog1/File1
root/Catalog2/File2
root/Catalog2/Catalog3/File3

[poli-smen]

Сообщение от morebeauty

Не совсем понял вопроса, но приведу пару столбцов для примера на всякий случай

ID / Имя объекта / Тип объекта / содержит объекты (перечисление ИД)
1 / root / root / (2)(3)
2 / Catalog1 / Catalog / (5)
3 / Catalog2 / Catalog / (4)(6)
4 / Catalog3 / Catalog / (7)
5 / File1 / File / Null
6 / File2 / File / Null
7 / File3 / File / Null

И означать это будет, что база содержит 3 файла:
root/Catalog1/File1
root/Catalog2/File2
root/Catalog2/Catalog3/File3

Т.е. как я понял тип поля "содержимое" будет текстовым? Сразу говорю, что это неправильно. Как ты будешь через SQL-запросы работать с таким полем? Или как контролировать целостность?

[morebeauty]

Сообщение от poli-smen

Т.е. как я понял тип поля "содержимое" будет текстовым? Сразу говорю, что это неправильно. Как ты будешь через SQL-запросы работать с таким полем? Или как контролировать целостность?

Целостность должны контролировать методы класса (который я таки затрудняюсь написать), ну а содержимое будет текстовым (а как иначе поместить туда несколько численных переменных?).
По поводу отбора, тут все просто. Я ведь не зря поместил ИДшники в скобки, искать можно будет по лайку с жестким совпадением (поле содержит "(3)", например).

[poli-smen]

Сообщение от morebeauty

Целостность должны контролировать методы класса (который я таки затрудняюсь написать), ну а содержимое будет текстовым (а как иначе поместить туда несколько численных переменных?).
По поводу отбора, тут все просто. Я ведь не зря поместил ИДшники в скобки, искать можно будет по лайку с жестким совпадением (поле содержит "(3)", например).

Можешь конечно поизвращаться с именно такой структурой. Но в общепринятом виде вместо поля "содержимое" тебе нужно поле "ParentID" в котором будет указываться "ID" папки в которой находится объект. Тогда получим следующее:
ID / Имя объекта / Тип объекта / ParentId
1 / root / root / Null
2 / Catalog1 / Catalog / 1
3 / Catalog2 / Catalog / 1
4 / Catalog3 / Catalog / 3
5 / File1 / File / 2
6 / File2 / File / 3
7 / File3 / File / 4

[Pyro]

Сообщение от morebeauty

Гибкость.
Простота использования.
Не требует от программиста умения работать с базами данных.

похоже на маршалинг/сериализацию
то есть например есть objectlist, в нём другие objectlist-ы (типа папки) и объекты(файлы), всю гору объектов можно целиком сохранить/загрузить (xml/json), и без индексов

есть ещё mongo, с индексами, своим языком запросов и нужно запускать отдельный процесс для сервера

оба случая без фиксированной схемы и с любой вложенностью

[poli-smen]

Сообщение от Pyro

похоже на маршалинг/сериализацию
то есть например есть objectlist, в нём другие objectlist-ы (типа папки) и объекты(файлы), всю гору объектов можно целиком сохранить/загрузить (xml/json), и без индексов

есть ещё mongo, с индексами, своим языком запросов и нужно запускать отдельный процесс для сервера

оба случая без фиксированной схемы и с любой вложенностью

Я когда-то интересовался технологией разрабатываемую ТС, которая называется ORM (Object-relational mapping). Даже нашёл несколько реализаций на Delphi ("Bold for Delphi", "ObjectView", "tiOPF", "TMS Aurelius"). Но потом интерес к этой технологии у меня пропал и я так её и забросил...

[Pyro]

честно говоря не знаю чем сейчас пользуются в дельфи, в рубях все используют или orm или подобные штуки (вот идеальный случай – описал объекты, отношения, и используешь их) в дельфи как я понимаю это делается через gui

а тс что хочет я не понял, можно взять на самом деле папки и файлы и вместо select использовать findfirst...

[morebeauty]

похоже на маршалинг/сериализацию
то есть например есть objectlist, в нём другие objectlist-ы (типа папки) и объекты(файлы), всю гору объектов можно целиком сохранить/загрузить (xml/json), и без индексов

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

Мне то всё равно как у тебя всё будет организовано, я просто написал как это правильно/общепринято делается.

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


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

[Freeman]

Сообщение от morebeauty

Я обычно не доверяю чужим методам. По возможности стараюсь для всего писать свои функции

Вот это -- да, вот это -- я понимаю! Видимо, каждый дельфист должен заново открыть для себя ООП и попытаться втиснуть его в реляционную модель. Для получения опыта -- почему бы и нет? Опыт -- штука полезная.

Сообщение от morebeauty

Плюсы такой модели:
Гибкость.
Простота использования.
Не требует от программиста умения работать с базами данных.

А вот тут хочу вас разочаровать: все плюсы надуманны от начала и до конца.

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

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

Хочется сделать самопальный ORM? Делайте. А вот преимущества из пальца высасывать не надо. Мы и так понимаем, что это вам просто интересно.

Хотя для начала я бы посмотрел тот же SQLite. Его теперь и Opera, и Firefox где-то внутри себя применяют. Не знаю только, для чего.