"мы так уже три года делаем, чего ты пристал"

Во во

в общем, у меня был очень печальный опыт с этим говном

а потом "да не знаю я, как там скидка посчиталась"

Самое веселое, что очень часто встречаю глупейший касяк при разработке на pl/sql, когда функция возвращает несколько значений, а прописывают, что функция ничего не вернула

"ее Влад делал, его спрашивайте"

/stat@combot

combot.org/chat/-1001045152752

/stat@combot

combot.org/chat/-1001045152752

"да на хранимках сделаем"

форич в пхп на датасетах в 10-20 тысяч строк конечно будет мгновенным ;)

Ну я собственно про то же.Даже если тупо как хранилище использовать можно проблем огрести.Но тут хотя бы не все запросы переписывать.Это не считая того что тюнить всё с нуля придётся.Тем более что с одного уникума на другой переезжаете.У нас тут витает идея с mssql на postgres переехать.Но все понимают что это по сути займёт примерно столько же времени что и разработка с нуля и мы хотя бы понимаем что это в принципе реально и нам хватит возможностей postgres.А ещё надо будет научить программистов oracle перестать думать на оракле

"ее Влад делал, его спрашивайте"

Я только заголовок написал,тело не моя работа

Ну я собственно про то же.Даже если тупо как хранилище использовать можно проблем огрести.Но тут хотя бы не все запросы переписывать.Это не считая того что тюнить всё с нуля придётся.Тем более что с одного уникума на другой переезжаете.У нас тут витает идея с mssql на postgres переехать.Но все понимают что это по сути займёт примерно столько же времени что и разработка с нуля и мы хотя бы понимаем что это в принципе реально и нам хватит возможностей postgres.А ещё надо будет научить программистов oracle перестать думать на оракле

а в чем проблема то ? переезжали даже с Монги на постгрес, и заняло это порядка 2-3 недель.

между рсубд попроще будет

Выше написали-смотря какая логика находится на стороне sql-сервера

Точнее сколько её там

форич в пхп на датасетах в 10-20 тысяч строк конечно будет мгновенным ;)

великолепный аргумент

мы тут все сидим и обмазываемся пыхом

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

Я такое видел.

ну так вот, ЭТО БЫЛ НЕ Я

!111

но если серьезно, то там у людей посерьезней процедурок проблемы

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

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

я за то, чтобы считать, а не вешать ярлыки сходу. Что там у оракла с политикой лицензирования? Особенно если оно в виртуалке, особенно если виртуалка на ферме или как там это называется. Чот мне припоминается, что если у тебя виртуалка плавает по 10 физическим серверам, в каждом из которых по 8 ядер, то оракл хочет денег за 80 ядер. А МС, если твоя БД для приложения на 5000 юзеров - за 5000 конкурентных лицензий. Если специфичных запросов надо переписать три штуки, то может оказаться сильно дешевле свалить на MySQL.

Ну я собственно про то же.Даже если тупо как хранилище использовать можно проблем огрести.Но тут хотя бы не все запросы переписывать.Это не считая того что тюнить всё с нуля придётся.Тем более что с одного уникума на другой переезжаете.У нас тут витает идея с mssql на postgres переехать.Но все понимают что это по сути займёт примерно столько же времени что и разработка с нуля и мы хотя бы понимаем что это в принципе реально и нам хватит возможностей postgres.А ещё надо будет научить программистов oracle перестать думать на оракле

о, а вы и считаете. Ну, за понимание. ?

даже интересно почему на mysql а не на постгрес ?

я за то, чтобы считать, а не вешать ярлыки сходу. Что там у оракла с политикой лицензирования? Особенно если оно в виртуалке, особенно если виртуалка на ферме или как там это называется. Чот мне припоминается, что если у тебя виртуалка плавает по 10 физическим серверам, в каждом из которых по 8 ядер, то оракл хочет денег за 80 ядер. А МС, если твоя БД для приложения на 5000 юзеров - за 5000 конкурентных лицензий. Если специфичных запросов надо переписать три штуки, то может оказаться сильно дешевле свалить на MySQL.

Мне кажется, ты перепутал лицензии ?

Мне кажется, ты перепутал лицензии ?

ой-вей, до тех пор, пока не я плачУ, и даже не меня спрашивают, за что платить, мне-таки не очень интересно запоминать детали

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

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

Ну и обычно знают одну какую-то платную субд и парочку бесплатных.Так что выбирать не приходится

День добрый. Вопрос от нуба - есть таблица | id | user | referral (id того кто пригласил) | ; Если значение атрибута зависит от ключа какого-либо кортежа в этой же таблице - имеет ли такой подход право на жизнь или лучше разделить на две таблицы (юзеров и рефералов)?

тоже нуб ?, т.е. я (студент заочный), думает что имееет

хорошо, а если добавить еще два атрибута (| выплачено денег с X | выплачено с рефералов |)? У меня опыт в проектировании в бд только теоритический (в универах щас учат строго соблюдать нормальные формы, вопросов производительности там не касаются)

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

конкретно выплаты хранятся отдельной таблицей, в формате | id | id юзера | ... |

День добрый. Вопрос от нуба - есть таблица | id | user | referral (id того кто пригласил) | ; Если значение атрибута зависит от ключа какого-либо кортежа в этой же таблице - имеет ли такой подход право на жизнь или лучше разделить на две таблицы (юзеров и рефералов)?

Дели

Таблица юзеров и таблица рефов

Один ко многим классический кейс

Таблица юзеров и таблица рефов

А можете конкретные аргументы привести? Я долго курил гугл и теорию прежде чем задать вопрос в чат, ну в универах у нас учат "меньше сущностей (таблиц) - лучше бд" (те, кто учат, по крайней мере учебник Дейта прочитали, в отличии от меня)

А можете конкретные аргументы привести? Я долго курил гугл и теорию прежде чем задать вопрос в чат, ну в универах у нас учат "меньше сущностей (таблиц) - лучше бд" (те, кто учат, по крайней мере учебник Дейта прочитали, в отличии от меня)

Если бы курил, не спрашивал

А можете конкретные аргументы привести? Я долго курил гугл и теорию прежде чем задать вопрос в чат, ну в универах у нас учат "меньше сущностей (таблиц) - лучше бд" (те, кто учат, по крайней мере учебник Дейта прочитали, в отличии от меня)

меня больше учили "больше сущностей, больше!!!, разделяй все!!!!"

И за за этого мои модели данных как мне кажется были слишком перегружены сущностями

Если бы курил, не спрашивал

значит не то курил, ок, в любом случае спасибо

Во всем должна быть мера

Это реально две разные сущности просто

Реф не обязательно юзер может быть, так же?

Количество лучше дели

Таблицу юзеров ваще засирать не стоит нигде

реф может быть юзером как раз таки

реф может быть юзером как раз таки

А может не быть?

точнее должен быть юзером

В любом случае я вижу один ко многим

Один юзер, много рефов

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

Автор той небольшой бд, что досталась мне в руки, вообще хранил рефералов в сессии (и записывает их в куки, соответственно браузер закрыт - реферал пропадает, в таблицу выплат адресс рефералов он зачем-то записывал)

В моем понимании юзеру может только один человек инвайт выдать, разве нет? Или тут другие рефы?

один юзер = много рефов, всё правильно

Каждый юзер может пригласить кого-то ещё.

ERROR: S client not available

Дерево почти бесконечное

если тебе нужно получать это дерево (кто кого пригласил то тогда дели)

если нет, то не вижу смысла делить

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

делать поиск всех рефералов юзера необходимости нет

вложенность 1 всегда

я бы тогда не стал делить

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

Что-то я или туплю или не понимаю зачем из делить в любом случае. У пользователя есть Id и реферал - Id другого пользователя. Куда ещё базу нормализовать?

полная таблица щас так | id | юзер | реферал (id строки в текущей же таблице) | выплачено от X | выплачено от рефералов |

ну и сам код - выплатить юзеру, если его кто-то пригласил - выплатить % и ему

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

Кеш, наверное, лучше не в базе хранить в этом случае

полная таблица щас так | id | юзер | реферал (id строки в текущей же таблице) | выплачено от X | выплачено от рефералов |

я бы не стал делить

Кеш, наверное, лучше не в базе хранить в этом случае

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

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

кеш это всмысле таблицы выплат?

кеш это всмысле таблицы выплат?

сумма всех выплат для данного юзера

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

пересчет полей таблицы (выплачено от X | выплачено от рефералов |) идет только при просмотре профиля пользователя?

может глупый вопрос но мне интересно

или будешь обновлять при каждой вставке в таблицу выплат,

?

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

пересчет делать не имеет смысла как раз таки если добавлять атрибут с суммарным количеством выплат (у меня в данном случае "выплачено от X"), его каждый раз просто пересчитывать нужно

я не думаю что моя схема на 100% правильна, если гуру ткнут носом - буду рад

я бы разделил на 3 таблицы вообще: отдельно хранить юзеров(что,наверное, есть) отдельно хранить связь реферал-юзер отдельно хранить выплаты от юзера/рефералов

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

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

мысль здравая

поправка - добавив атрибут к таблице юзера