Есть в каком нибудь редакторе схема? А то так очень тяжело воспринимается... И еще раз четко сформулировать задание

Я сейчас вообще через кассандру пытаюсь продратся. Интересно, но заверчено как в детективе. Надеюсь что убийца не панда.

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

Есть в каком нибудь редакторе схема? А то так очень тяжело воспринимается... И еще раз четко сформулировать задание

мне понадобится время для этого)

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

ага, а джоины они вообще зло

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

ага, а джоины они вообще зло

Много джойнов не бывает :)

А кто может накидать названий olap'ов, которые имеют фри/комьюнити/opensource версии?

Желательно, которые не стыдно в прод закинуть?

Желательно, которые не стыдно в прод закинуть?

В смысле что бы названия поповсовей и похвастаться не стыдно? :)

Чтобы работало нормально, а не просто имело бирку "olap"

Чтобы работало нормально, а не просто имело бирку "olap"

Спарк+кассандра?

Доброе утро. Подскажите, как обычно реализуется хранение деревьев в реляционных БД, когда паренты могут ссылаться на разные сущности? Например организационная структура предприятия

Доброе утро. Подскажите, как обычно реализуется хранение деревьев в реляционных БД, когда паренты могут ссылаться на разные сущности? Например организационная структура предприятия

Вы конкретизируйте. А то деревья это .. такое.. распывчатое

Указывать явно, типа Id, ParentId не получится, т.к. FK не может ссылаться на разные PK. Вот и интересуюсь, как правильно такие вещи хранят

Там вообщ завал с сесиями ? Представляйте что вы все хотите хранить в табличке экселя

Юзер | отдел

Какие нафиг деревья

Юзер может включать в себя весь отдел? Странненько Не проще ли сделать как посоветовал Al выше. Таблица юзеров и таблица отделов. У юзеров добавить поле "начальник (или кто он там) для отдела: ", ссылающееся на отдел по id. Ну и поле для указания родителя, разумеется, добавить надо.

Я так подозреваю что там 50 юзеров и 7 отделов. Проще бабушку с блокнотом посадить. Пусть рисует.

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

Юзер может включать в себя весь отдел? Странненько Не проще ли сделать как посоветовал Al выше. Таблица юзеров и таблица отделов. У юзеров добавить поле "начальник (или кто он там) для отдела: ", ссылающееся на отдел по id. Ну и поле для указания родителя, разумеется, добавить надо.

Проще юзерам раставить ид отдела А отделам проставить ид начальника

Все счастливы

2 таблички по 2 колонки

Не считая ид

Предлагаю растреливать за предложения строить графы :)

Предлагаю растреливать за предложения строить графы :)

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

Не самый разумный

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

Зачем? Зачем отражать в бд то как работает логика приложения?

Бд это грубо говоря шкаф с бамажками.

Пометили каждый листик (ид, номер отдела.. сколько должен..) и потом достаете когда нужно и подставдяете по месту

И ведь картотеку библиотечную в пример не приведешь. Большинство уже и не знают что такое библиотеки:)

И ведь картотеку библиотечную в пример не приведешь. Большинство уже и не знают что такое библиотеки:)

dll? ?

dll? ?

https://s00.yaplakal.com/pics/pics_original/2/9/8/415892.jpg

Зачем? Зачем отражать в бд то как работает логика приложения?

Т.е. не нужно ничего усложнять и как-то пытаться группировать. К примеру в системе есть таблицы "Организация" и "Пользователь" у каждого из них может быть свой баланс. В каждую таблицу добавить такую колонку и всё? Тогда для логирования операций по счетам организаций делать отдельную таблицу, а по счетам пользователей отдельную? и если мне нужно будет вывести общий лог то делать выборку из обоих таблиц и мерджить их?

Т.е. не нужно ничего усложнять и как-то пытаться группировать. К примеру в системе есть таблицы "Организация" и "Пользователь" у каждого из них может быть свой баланс. В каждую таблицу добавить такую колонку и всё? Тогда для логирования операций по счетам организаций делать отдельную таблицу, а по счетам пользователей отдельную? и если мне нужно будет вывести общий лог то делать выборку из обоих таблиц и мерджить их?

Ну примерно так. Каждой группе сущностей свою табличку. И маркировать каждую отдельно как она соотносится с другими. В этом и есть смысл картотеки

Смысл бд это долгосрочное структурированное хранение переменных в больших обьемах.

Спасибо за ответы.

Спасибо за ответы.

Просто смотри на это так. Есть например юзеры и у них есть какие то признаки у каждого. Отдел в котором работают. Рост. Цвет машины. Есть отделы и у них у каждого тоже есть какие то признаки. Начальник. Количество стульев. Этаж. Цвет двери. Ну и так далее. Делаешь таблички и заносишь в них данные. А потом можешь делать выборки по любым признакам включая сложные типа какого цвета дверь открывает сотрудник ростом 190см на красной машине.

Краткий вводный курс в базы данных от дальнобойщика. Гыы

Краткий вводный курс в базы данных от дальнобойщика. Гыы

Понял, еще раз спасибо.

возьми графовую бд и не парься. будет удобно хранить и манипулировать - neo4j, например.

возьми графовую бд и не парься. будет удобно хранить и манипулировать - neo4j, например.

the bell has rung

?

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

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

Вопросец есть: есть большая таблица с данными торгов между людьми, содержит поля Продавец, Покупатель, Сколько Товара, Время Сделки. Есть предложения как найти в ней замкнутые циклы Nой длины(гоняют товар по кругу) с допуском по объёму товара?

Допуск в процентах от объёма

СУБД оракл 11gR2

Пытался через иерархические, но у меня какая-то дичь выходила

Вопрос можно более нормально сформулировать?

А то вопросы бизнеса тут половина, если не больше, могут не понимать

Вопрос можно более нормально сформулировать?

Как отловить ситуации, когда, например, Есть 3 человека A, B и C, и они продают друг другу товар, т.е. А продаёт B 100 единиц, B продаёт С 100 ед и С продаёт А 100 ед. При этом их участников цепочки может быть больше и количество товара не всегда одинаковое.

Не совсем понятно, какой результат и в каком виде нужен?

Нужно получить эти сделки-циклы в каком-нибудь виде)

Вид особой роли не играет - всегда можно подогнать под требуемый

Т.е. вы сами не знаете, что надо?

нужны цепочки из сделок, а как они будут выводится не важно

Разве сама таблица, это не сделки?

Кажись я понял

т.е. в конце цепочки товар возвращается к участнику сделки который эту цепочку породил?

Тут иерархия

т.е. в конце цепочки товар возвращается к участнику сделки который эту цепочку породил?

да

Он хочет список людей, через которых проходил товар

ERROR: S client not available

Если не секрет, то как это вообще происходит? Не в плане манипуляций с записями, а зачем продавцу его собственный товар?

мухлюют

Профит же

накручивают бонусные баллы или чего покруче

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

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

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

Да, с кругами внутри цепочки тоже проблемы(

Тут надо думать, как это представлять в табличном виде... Либо брать не реляционки

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

Кто-то знает, как это сделать по другому?

не очень понятно по какому критерию считать сделку участником цепочки

Повторения

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

Повторения

повторения чего?

Продавец = покупатель

ну какбы, "а ты докажи, что не Аллах"(с), без дополнительных данных типа "вида продукции\услуг" будет непросто

Кто-то знает, как это сделать по другому?

только долгие извращения в голову приходят. например, считать, что вся таблица - это связи в графе от юзера к юзеру с весом равным объему, и пытаться реализовать в процедуре какой-нибудь из алгоритмов поиска цкилов. на pl/sql это будет очень больно скорей всего, но оракл позволяет писать процедуры еще и на жабе. но получается таки вообще содом

блокчейн надо внедрять :)

и как он поможет против циклических сделок?

сами-то по себе они инварианты не нарушают

не знаю как, но в интернетах обещают что поможет :)

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

т.е. владеет ли система полной информацией о происхождении товара и может ли полностью менеджить его историю?

не знаю как, но в интернетах обещают что поможет :)

да я однажды ходил по такой ссылке

Вопросец есть: есть большая таблица с данными торгов между людьми, содержит поля Продавец, Покупатель, Сколько Товара, Время Сделки. Есть предложения как найти в ней замкнутые циклы Nой длины(гоняют товар по кругу) с допуском по объёму товара?

https://explainextended.com/2009/05/18/finding-loops-in-a-tree/

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

Система знает всё.

https://explainextended.com/2009/05/18/finding-loops-in-a-tree/

Спасибо. Почитаю.

Да, с кругами внутри цепочки тоже проблемы(

Почему всё-таки не hierarhical queries?

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

Вот именно. Что есть только один смысл брать графовую бд. Когда у тебя есть данные представленные в виде динамических векторов и они постоянно меняются. Графовая бд ничего никуда не рисует.

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

И организационную структуру в той же neo4j вам придется ручками прописывать каждую ноду что бы оно было похоже на то что на картинке организации вам видется.

кто уже настраивал patroni + etcd можно пример шаблона patroni и etcd.cfg ?

Как отловить ситуации, когда, например, Есть 3 человека A, B и C, и они продают друг другу товар, т.е. А продаёт B 100 единиц, B продаёт С 100 ед и С продаёт А 100 ед. При этом их участников цепочки может быть больше и количество товара не всегда одинаковое.

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