Нотация для мэппинга

мэппинга
кейс
парсинга

Плак ;_;

Ну напиши, как не плак, я даже не обломаюсь и поправлю. Только, что бы понятно было.

Не понял, что ты хочешь, и чем тебя неустраивает классическая математическая нотация для множеств.

Может он хочет либу для эмуляции физики в игрушке.
(Судя по списку эта мотивация представляется наиболее вероятной)
Правда вот зачем python?
Для того чтоли чтобы у пользователей появился повод к покупке AMD FX-8320?

мэппинг

Отображение

кейс

Случай

парсинг

Разбор (чувствую, сейчас понабегут)

Боюсь, что я, да и целевая аудитория не осиливши будет :)

Но, если одаришь примером, как в такой нотации можно записать и распарсить например, что поле каждого 3ий элемент из одного набора (поле), нужно сложить с каждым элементом из двух других (тоже заданное поле), и если получившееся чиселко стало допустим >=3 и <=10, то в один результирующий набор мы пишем 'A' а в другой добавляем две строки с полями:

 'A' <чиселко> <заданное поле из 1ого набора данных> <сумма двух заданных полей из второго набора данных> 

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

В общем случае я ничего лучше xslt (представить структурированные данные в виде xml не так уж и сложно) - пока что не придумал. Но руками такие преобразования писать - не очень наглядно. А редакторы стоят не кислых денег.

Не не, там гольный бизнес - задача, отгородить разработчика от понимания бизнеса, и перенести задачу составления такого отображения, людям которые в нём действительно разбираются, читай БА.

если руками править то лучше json не придумали.

суть не очень ясна, но может взгянуть на описание бизнес процессов в UML?

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

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

А в виде чего разбирающиеся люди свои измышления формализуют на данный момент?

JSON

JSON - это не нотация... это просто способ представления данных, если что.

Про то и вопрос.

SQL же

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

Джсон у тебя уже есть, осталось придумать, как его применять. И это уж тебе виднее.

покрывающая вариант обьединения 3ех наборов данных в 2-ва, с дополнительными элементарными(читай арифметическими) расчетами.

Здесь подходит ёбалисп

(yoba nabor1 nabor2 nabor3 (dopolnitelnye raschioty))

Боюсь среднестатистический БА не оценит ёбатехнологии.

И где в json система обозначений для описания отображений наборов данных, вики чтец ты наш о мудрый?

можно скобки по другому поставить

и на отступах

yoba(nabor1 nabor2 nabor3):
    dopolnitelnye
    raschioty

напиши eDSL короч, а потом в питоне еваль

Задумка интересная, но xslt, тут выглядит проще. Ибо иерархия имеется, а в терминах реляционных БД получится много буков и лишних сущностей.

xslt выглядит проще $WHATEVER? O_o

Впрочем, тебе виднее.

Таже фигня что с json, я не хочу изобретать свой dsl, я хочу найти готовый. С докой. Возможно даже с инструментами.

{union: [{map: transform1, set: [huita1, huita2, huita3]},
         {map: transform2, set: [heroten, pizden, dzhigurden]}]}

Проблемы с воображением?

Ну проще для записей с четко выраженной иерархией - как минимум короче чем вложенные SELECT INTO.

Тогда тебе нужно найти, как называются твои операции. Например, если это известные операции из теории множеств, то тебе нужна либа для питона с операциями над множествам и т.п.

Проблеммы с телепатией. Мне так то не для себя такой мэппинг надо написать, мне надо что бы человек для меня его составил.

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

дело 5ти минут
формализуй

не продолжай.jpg

Ясно, у тебя с воображением тоже не очень видимо. А я уж испугался, что я один такой инвалид.

Сколько заплатишь за формализацию? Половину вперед.

И с тебя тз.

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

Но это в этот раз, а более типичный случай, всё таки список деревьев.

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

Свой же выкак наколеночный, ты формализовать не можешь, а денег каких то просишь. Не, считай ты не прошёл собеседование.

слив засчитан

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

Тебя никто не заставляет делать строгое подмножество SQL. Над деревьями тоже определяются языки запросов, от языков запросов для иерархических СУБД до XDuce:

addrbook[
  name["Haruo Hosoya"],
  addr["Tokyo"],
  name["Benjamin Pierce"],
  addr["Philadelphia"],
  tel["123-456-789"],
  name["Peter Buneman"],
  addr["Scotland"]]

Другое дело, что предъявленным в хедпосте требованиям это всё не отвечает.

А вот про языки запроса для иеррархических СУБД, мне видимо надо почитать, ибо от этой темы я сильно далёк.

Возможно предложишь какой нибудь энтри поинт?

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

А пример join'a для этого языка можешь так же набросать?

Выглядит этот xduce - слегка протухши. Да и не сказать что он сильно нагляднее xslt или xquery.

Например, так:

rec1[f1["foo*"]] + rec2[f1["bar*]] => rec3[ouf1[f1], outf2[rec1::f2 + rec2::f2]]

Да и не сказать что он сильно нагляднее xslt или xquery.

Значит, xquery.

Ясно, ну раз за день ничего умнее xml и реляционной модели не придумалось, можно на этом и остановиться. Думаю я всё таки выберу xslt, ибо в нём имеется экспертиза у всех заинтересованных морд.

Ну и нахрен твои выкрутасы с JSON, если в нормальных ЯП это прямым текстом пишется?

List do(
 transform1 := method(select(>2))
 transform2 := method(select(<8))
)
curlyBrackets := method(call evalArgs)


{1,2,3,4} transform1 union({3,4,5,6,7,8,9,10} transform2) print

# ::: list(3, 4, 5, 6, 7)

ну раз за день ничего умнее xml и реляционной модели не придумалось

Даже если для твоего конкретного случая и существует серебряная пуля, данное тобой туманное описание не позволяет ее найти.