Это как, простите?
Ну вот так :)
Nikolay
Ayrat
Это отсутствие понимания что происходит!
Nikolay
Так это херня ещё)
Nikolay
Может ссылаться на другой документ из другого вида документации!
Vasily
Ну в общем или ты нам что-то не рассказываешь
Vasily
Или долго проект не проживет
Nikolay
Пока живёт
Ayrat
Да, есть мнение ты постоянно придумаешь дикие новые требования, которые выглядят как плохой дизайн
Nikolay
Это не я придумываю)
Nikolay
У них так работа построена
Ayrat
Тут есть ещё вариант - ты плохо замоделил
Ayrat
не надо сбрасывать со счетов этот немаловажный фактор
Vasily
Плохо тут не совсем подходящее слово
Vasily
ХУЕВО
Nikolay
Ну, про замоделил, изначально так было:
Проект
Объект
Титул
Документ
Nikolay
А потом постоянно накручивалось
システム
скюл сервер умеет в xml
and Oracle DB as well, also there is hierarchyid type, but for now it's better to use XML
also I'd move all relations describing into separate structure
On one project, private property market, we were using even neo4j for storing all relations
P.S. Sorry to long to use those site with translit)
Vasily
Вообще, ссылки обычно менеджатся с помощью кросс-таблиц
Vasily
А neo4j норм выбор, кстати
Vasily
ДЛя таких кесов
Ayrat
короче, я тоже когда-то делал так. Потом понял что такие структуры невозможно расшивать или внедрять в середину новый уровень и перестал делать реляции таким образом
Vasily
*кейсов
Ayrat
я ток хотел написать - потом я нашёл графы
Ayrat
ты прям мысли прочитал
Vasily
Я знаю только еще одну такую бд
Vasily
В которой это делать совсем удобно
Vasily
Всякие BPM удобно строить
Nikolay
Проблема в том, что изначально было всё сильно просто
Vasily
Но неудобно работать с большими массивами данных
Nikolay
А теперь так
Nikolay
И не вижу смысла всё переписывать сейчас
Nikolay
Работает - не трогай
Vasily
Ну дальше тебя под этим похоронит
Nikolay
Тем более проект не завершён, и ещё будут впереди доделки переделки
Vasily
ПОтому как , судя по косвенным данным, простые бизнес кейсы уже требуют гигантской работы
Ayrat
короче, последний раз я расшивал (до прода не доехало, но в деве крутилось, а потом я уволился) громадную срань. И т.к. в разных местах системы были разные требования к иерархии, и на митингах все пытались найти некую среднюю иерархию которая бы всех устроила (ну чтобы схему в SQL по старинке запилить), я втихую заебашил плоскую структуру, прописал связи отдельно. Потом натянул на граф и представил каждому структуру какую они хотели.
Было охуенно
Vasily
Ну так оно и бывает, когда единицей атомарности выбираешь не объект, а его свойство
Ayrat
т.е. как только у тебя появляется 3ий уровень вложенности - это звоночек что надо перестать делать то что ты делаешь
Ayrat
т.е. если есть допустим объект Документ, то он хранит только свои св-ва. и никогда связи на детей, родителей, это другая сущность и она не должна быть жёсткой
Ayrat
таким образом документы могут быть как на уровне проекта (без объекта), так и на уровне Оъекта (без титула) и пр
Vasily
Документ не хранит свои свойства
Ayrat
см выше
Vasily
А, ну ок
Ayrat
выше схему Николая
システム
Ну так оно и бывает, когда единицей атомарности выбираешь не объект, а его свойство
But as always, one moment here - you need to monitor number of stored properties, at some point of time it could be a bottleneck and you need to pay a debt before everything will go down
Vasily
Не, это не проблема обычно
システム
Vasily
Решается шардингом как минимум
システム
Не, это не проблема обычно
we had case with >500M documents, some of them had literally dozens of thousands of versions
it was geodistributed, >30 DC, and there were cross links
yeah, but you need to be ready to shard the system
Nikolay
Ayrat
а кейс у меня был такой, надо было составить всего лишь навсего календарь игровых событий в мире.
ну короче, одни говорили так
Вид Спорта
Страна
Чемпионат
ИгровойДень
Событие
А другие говорили
Вид Спорта
Страна
Чемпионат
Категория(кубок, дивизион, хз чо, просто лишний уровень на всякий случай)
Событие (и нахуй игровой день, дата зашита в событии)
А любители олимпийских игр вообще были вахуе от обоих структур и просили по-другому.
Короче, плоская структура типизированных объектов и связей между ними зашла как нельзя лучше
Есть страна с названием, есть вид спорта с правилами.
Событие игровое линкуется с нужными сущностями (с датой, с командами, с видом спорта, с чемпионатом и если надо, местом проведения)
при этом если связей нет, похуй, мы можем добавить в такую структуру любое событие в природе и не зависеть от ебанутой мысли DBA, у которого SQL головноо мозга
Nikolay
Хотя это не всегда прокатывает, бывает иерархия у самой сущности как бы
Vasily
Стремление нормализовать данные - в принципе ок
Vasily
Но я о том, что для каждой доменной области надо выбирать типы аккуратно
Ayrat
Стремление нормализовать данные - в принципе ок
ну короче данные по киберспорту не заезжали ни в одну схему.
Но были охуенные предложения добавить Страна=Интернет
Ayrat
короче такой подход гарантирует только наличие костылей
Ayrat
Тут надо от события отталкиваться, не?
не, потому что это опять приведёт к жёсткой структуре.
К моей схеме потом можно СНИЗУ события накрутить - ставки, игровые моменты, какую-то херню, неважно
Ayrat
но снизу это неправильное слово, т.к. тут нет иерархии
Ayrat
а если нет иерархии, не надо о ней думать! но надо думать о связях, да.
Короче, это опять - просто по-другому
Vladislav
читаешь вас тут и чувствуешь себя дураком
Vladislav
Vasily
Я себя вообще идиотом чувствую обычно
Hog
полным
Hog
Был у меня случай один - так получилось, что меня Ed Kmett интервьюировал - вот где жесть была
Hog
Забыл в какой чатик писал про Полли - в общем - я дебил :)
システム
Ayrat
Короче, плоская структура типизированных объектов и связей между ними зашла как нельзя лучше
Есть страна с названием, есть вид спорта с правилами.
Событие игровое линкуется с нужными сущностями (с датой, с командами, с видом спорта, с чемпионатом и если надо, местом проведения)
BTW, it is typical 6th NF
システム
six normal form, also known as domain-key form
Hog
6я нормальная форма :)
Nikolay
Нужно в NoSQL пилить!