LINUX.ORG.RU

Организация типизированных (в т.ч. типы пользователя) данных с комментариями в json?

 ,


0

6

Сабж.

В python есть pickle который хранит в т.ч. типы пользователя и автоматически импортит модули при десериализации, но pickle какой то маргинальный стал (чехарда с форматами и невнятные перспективы), хочется уйти на json. Кроме того pickle все равно не умеет хранить комментарии из коробки.

Нужно сохранять и загружать вот такое:

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

  2. ключи в исходных данных гарантированно текстовые отвечающие требованиям к питоньим идентификаторам.

  3. Типы параметров — все что есть в json из коробки (числа, строки, списки, словари) + что то пользовательское, м.б. сложное и требующее импорта сторонних модулей при восстановлении.

  4. некоторые из параметров могут быть снабжены комментариями (комментарий это строка)

  5. желательно что бы комментарий лежал рядом с параметром для улучшения читабельности .json - файла глазами.

Интересна не техника записи/чтения в коде, интересна сама структура данных.

Понятно что список импортируемых модулей можно хранить в каком то списке на верхнем уровне.

Можно сделать две параллельных структуры с типами и комментариями, но выглядит как извращение:

[{ 'a':1, 'b':2.5, 'c':[1,2,3]},
 {'c':'myvector.myvector3D'},
 {'a':'длина баскетбольной площадки', 'c':'куда бросать мяч'}
]

Можно загонять тип в имя параметра 'myvector3D c':[1,2,3], можно рядом с параметром класть какую то информацию '@c':['myvector3D', 'куда бросать мяч'] — но это все работает только если параметры лежат в словаре, скорее всего так и будет но что то может поменяться.

В общем много вариантов но хороших я не вижу;-(

@annulen

★★★★★

Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

Готовые решения интересны тем что у них какое то гуи есть и устоявшаяся идеология

Гуёв для посгреса я думаю на свете не меньше, чем для монги. По-хорошему конечно нужен гуй не для БД, а для предметной области. Но если оперировать гуями к базам, то идеология «табличка с данными» от РСУБД всё-таки ближе к людям, чем «свалка разнородных документов» от Монги.

annulen ★★★★★
()
Ответ на: комментарий от annulen

Это правда, некоторые вещи есть во всех расчетах. Но с поиском то проблем нет - расчетов (по меркам обычных СУБД) исчезающе мало.

Основной контраргумент против СУБД - расчет это не только записи в базе но и пачка (толстых) файлов. И эти фалы обрабатываются средствами ОС, в т.ч. расчет средствами ОС может перемещаться/уничтожаться. Как тогда следить за целостностью данных?

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

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

Но с поиском то проблем нет - расчетов (по меркам обычных СУБД) исчезающе мало.

Если их действительно мало, то индексы не понадобятся, можно полным перебором все запросы выполнять. Но БД в этом случае повышает удобство создания запросов. И в этом плане выбор между SQL и Mongo — это выбор между (более-менее) стандартизированным языком и языком, прибитым гвоздями к одной единственной реализации БД, к тому же проприетарной и с неясным будущим.

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

Ну это как раз то, что делает select. Можно, конечно, ещё и вьюху создать, и применять SQL-запросы уже к получившейся табличке, но это уже следующий порядок)

annulen ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.