извините. эксперты и юмористы.

извините. эксперты и юмористы.

У тебя есть более оригинальное решение?

get the job done вместо дбашного нытья что однажды в бородатом году я работал с eav, не зная как с ним работать, и мне не понравилось

get the job done вместо дбашного нытья что однажды в бородатом году я работал с eav, не зная как с ним работать, и мне не понравилось

Так скучно. Без нытья то как.

Если просто брать и делать все неаедомое что прилетает. Никто этого не оценит никогда. Не похвалит. Все будут думать что так оно и должно. Пока ты не свалишь от этой тоски

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

Зато все будут видеть что ты занят. А не приваливать тебе ещё всякого неведомого

Лол как вы еще с неструктурированными данными будете работать?

лол это потом это поддерживать, зачем городить бд в бд ?

где там бд в бд?

что такого в поддержке проектов?

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

не говоря уж про обеспечение целостности и консистентности данных

пошло затуманивание словами

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

когда айдишник пользователя может быть, а может не быть

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

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

а что ты пытаешься на свою одну модель натянуть все ?

на какую свою?

и где я натягиваю?

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

а для "а мы не знаем че там будет"

при чем здесь это?

при том что это частое использование еав

а в этом разговоре здесь это каким боком?

при том что структурировать данные зачастую проще

чем потом разгребать это дерьмо

а как это логически связано с предыдущими предложениями?

я вообще не понимаю, что здесь обсуждается

оно заметно :)

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

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

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

да нихрена она не ложится

с чего это в друг ?

потому что в одной транзакции одни атрибуты, в другой другие

будешь либо десять таблиц держать, любо нуллами жонглировать, выясняли же уже

я такое реализовывал, и чет все ок было

не умеешь проектировать финансовые системы не берись

на моей машине все работает

сперва добейся

боже

что тут еще сказать

причем тут это ?

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

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

оооох

у тебя все ох

а у тебя ни одного аргумента

что не послушай :) то хранимки говно, то еав хорошо :)

в стопятидесятый раз

описываемая ситуация сама по себе говно

там нет хороших решений

нормальная ситуация

я бы даже сказал классическая

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

А что не так с концепцией ?

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

опять же, какое отношение это имеет к вопросу?

к какому ? чувак пришел с вопросом как делать ему фин систему в проекте, требования из будущего и этого вот всё, ему посоветовали EAV зачем-то. Там где он ненужен. Я сказал что лучше избегать в чем проблема то ?

к моему

к какому из ?

ну ты вроде на последний отвечал

я на него ответил.

ну и какое отношение к нему имеет очередной ответ про то, что никто не умеет нормально работать?

прямое

Смотри, я говорю: "это не лезет в концепцию". Ты говоришь: "это классическая проблема", я выпадаю, потому что частота встречи с проблемой никак не коррелирует с тем, лезет ли проблема в концепцию. Я говорю: "можно использовать eav". Ты говоришь: "eav нельзя использовать, потому что его используют там, где не знают, что хранят", и я опять выпадаю, потому что это опять никак не коррелирует. "Про какую целостность мы можем говорить, если поля абсолютно легально могут принимать любое значение?" - "Оно отлично ложится в структурированные данные". "Оно не ложится в структурированные данные, тут либо eav, либо насилие над одной таблицей, либо по таблице на тип и насилие над людьми, которым с этим работать" - "Я реализовывал (без деталей, как), все было в порядке"

ERROR: S client not available

1) Еще раз, если на этапе проектирования заложить стандартную бухгалтерскую систему + по мере развития добавлять доп таблицы при необходимости. Нет необходимости в EAV

2) Я говорю что конкретно в этом кейсе EAV вреден. Если идти дальше то он приведет к проблемам с производительностью раньше чем с таблицами

3) Поля в финансовых документах имеют конечный вид и любые формы не принимают

4) я ничего не говорил что надо пихать в одну таблицу.

4) я ничего не говорил что надо пихать в одну таблицу.

Господи, опять. Я же ничего, НИЧЕГО не писал про то, что ты предлагал такое делать.

Оно не ложится в структурированные данные, тут либо eav, либо насилие над одной таблицей, либо по таблице на тип и насилие над людьми, которым с этим работать

твоя вроде фраза

Ага. Это моя реплика.

будешь либо десять таблиц держать, любо нуллами жонглировать, выясняли же уже

а в чем тут проблема?

он просто монгодбист )

it is not web scale !

шучу конечно

кстати, по аналогии eav в вертики реализованы flex table ?

но честно, я их еще не тестил в нормальном виде

в том, что надо либо выбирать из десяти таблиц, либо писать недебажимые запросы

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

в том, что надо либо выбирать из десяти таблиц, либо писать недебажимые запросы

погоди, вот летит ко мне поток транзакций (мы же все еще про тот пример?) я беру этот поток и разгребаю и кладу так, как мне удобно

в чем тут проблема?

у меня щас под боком система с EAV, могу сказать что с ним как раз получаются запросы в 800-1200 строк. Рекурсивные да. Вот это действительно сложно дебажить :)

зачем нужен eav?

тебе удобно в одной или в десяти?

удобно что?

погоди, вот летит ко мне поток транзакций (мы же все еще про тот пример?) я беру этот поток и разгребаю и кладу так, как мне удобно

этот разговор только что стал еще лучше, чем был

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

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

и в чем проблема то выгрести из 10 таблиц ?

я вот в упор не понимаю.

что выгребать из 10 таблиц?

я не понимаю

ну, тебе же эти данные читать потом надо, верно?

разнородные данные)