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

✓ просто не надо было брать орм

Fike почему байку то ? :) я вот регулярно от питонистов получаю запросы с IN () в 10000 -20000 тысяч элементов

слышу эту байку уже пятый год

Не байка, единицы генерят нормально

откуда у вас in в орме?

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

Fike почему байку то ? :) я вот регулярно от питонистов получаю запросы с IN () в 10000 -20000 тысяч элементов

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

джанга при ленивой загрузки любит

монга говно же

Не такое уж и гавно

✓ монга больше не гавно

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

можно было бы использовать CTE и джойны и это отработало на порядки быстрее.

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

ленивая загрузка 10000 элементов? что?

ленивая загрузка 10000 элементов? что?

вот и я говорю.

тут не в орме проблема ей-богу

можно было бы использовать CTE и джойны и это отработало на порядки быстрее.

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

часто бывает запрос на элементов 30: это явно сбор деталей по странице неоптимизированный, обычно не требует правок, а вот на 2000… надо научить временные таблицы явно

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

вот на следующем шаге мы и слышим "орм тормозит"

тут не в орме проблема ей-богу

это поведение джанговского орм по дефолту.

чуть не забыл

✓ питон блевня и ссанина

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

но у нас же ORM ))) а скл знать не надо!

✓ используй Crystal :)

я не знаю что там в джанге. но нормальный орм не вылезает за пределы селектов-делитов и джойнов

))))

ORM

Не сильно помог

хибернейт любит в IN запросы пихать

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

но у нас же ORM ))) а скл знать не надо!

Кто-то использует ORM неправильно -> ORM нинужен

пока не видел таких у себя

не то что не нужен, я пытаюсь использовать ORM в своих пет проектах

где-то удобно

я давал ему шанс!

пока не хочешь чего-то странного.

не надо хотеть странного блин

когда хочешь чего-то странного, берешь jdbc, python-драйвер для любимой СУБД - и делаешь

но в целом... впечатления не самые радостные :)

все проблемы внезапно уйдут

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

это планомерное использование всех преимуществ СУБД

Не всегда, зависит от задач и планируемых нагрузок.

Не всегда, зависит от задач и планируемых нагрузок.

Соглашусь! В мелкие проекты я бы такое не тащил

Транзакции по двадцать минут выполнялись

Индексы - нет, не слышали?

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

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

И про нормальные формы дружно забываем, да

✓ забыть про нормальные формы

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

с миграциями как раз всё ок

✓ забыть про нормальные формы

не упомянули про "а вдруг надо будет сменит БД"

✓ не забыть сменить бд

с миграциями как раз всё ок

Что ОК? Я посмотрю на тебя,как ты будешь логику функций с pl/sql переносить куда-нибудь без функций

куда нибудь это куда ?

✓ а что если переедем на sqlite

у меня есть на pl/sql API он стандартизирован и описан, внутри меняется хоть модель данных, хоть функции что угодно, API остается тотже. Что я делаю не так ?

И главный вопрос - зачем ?

выносишь логику в бд

а потом меняешь БД и жалуешься. норм план.

✓ вынести мусор и логику в бд

Вьюхи вьюх и там циклы и по ним селекты

Вьюхи зло, база сколько весила?

а потом меняешь БД и жалуешься. норм план.

"меняешь бд" - это норма, начиная от организации DWH и заканчивая миграцией

вот и переноси потом эту логику

я бы не сказал что норма. обычно это пытаются это сделать те кто не понимает чего хотят от БД.

и никто не мешает витринны данных из дата лейка делать.

ну или попытки скрестить бульдога с носорогом

Вьюхи зло, база сколько весила?

Да с хера ли зло

Это не сайтики

Fike почему байку то ? :) я вот регулярно от питонистов получаю запросы с IN () в 10000 -20000 тысяч элементов

А что в этом такого? Если там составной индекс и колонка не последняя, если рэнж впихнуть, то юз индекса оборвёться

✓ мы тут не сайтами занимаемся

ERROR: S client not available

А что в этом такого? Если там составной индекс и колонка не последняя, если рэнж впихнуть, то юз индекса оборвёться

там есть линейная зависимость от количества элементов в выражении.

✓ используй Crystal :)

Водку?

я бы не сказал что норма. обычно это пытаются это сделать те кто не понимает чего хотят от БД.

ну да, т.е. сначало взяли мускул, потом БД выросла, решили мигрировать на КХ, нефига не норма и народ не понимает, что хочет от БД ???

ну да, т.е. сначало взяли мускул, потом БД выросла, решили мигрировать на КХ, нефига не норма и народ не понимает, что хочет от БД ???

что мешало под аналитику воткнуть КХ рядом ? и хранить эти данные там ? а мускуль оставить для остального ?

в 99% случаев люди хотят получить серебряную пулю которая решит их проблемы. Вместо того чтобы сесть и подумать где какие данные хранить и как их между собой связывать, всё сводится "выкинем mssql и воткнем постгрес, а постгрес тоже говно берем кликхаус"

серебряную

fixed

в 99% случаев люди хотят получить серебряную пулю которая решит их проблемы. Вместо того чтобы сесть и подумать где какие данные хранить и как их между собой связывать, всё сводится "выкинем mssql и воткнем постгрес, а постгрес тоже говно берем кликхаус"

вспоминается кейс убера

что мешало под аналитику воткнуть КХ рядом ? и хранить эти данные там ? а мускуль оставить для остального ?

потому что мускуль уже дохнет от объемов, где у тебя скорость то будет?

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

хотя у меня сейчас подобная логика ??

я собираю данные с оракла, мускула и мсскл и загоняю все в vertica

но у меня именно DWH, а не миграция

ну универсальных решений не существует...

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

как в SQL Server Management Studio выгрузить таблицу в SQL скрипт?

типа дамп

Есть бд Oracle 11g, пытаюсь на сервере rman'ом подключиться используя operating system authentication: rman target / Получаю ошибку: TNS:permission denied На сервер зашёл под рутом, рут пользователь находится в группе dba

как в SQL Server Management Studio выгрузить таблицу в SQL скрипт?

Вроде тыкаешь по базе данных правой кнопкой, там будет что-то типа "Tasks", и в нём "Export"

как в SQL Server Management Studio выгрузить таблицу в SQL скрипт?

бэкап

Вроде тыкаешь по базе данных правой кнопкой, там будет что-то типа "Tasks", и в нём "Export"

да уже нашел это, но непонятно что выбирать в этом мастере на шаге "choose a destination" там вроде нету в списке sql скриптом экспортнуть

да уже нашел это, но непонятно что выбирать в этом мастере на шаге "choose a destination" там вроде нету в списке sql скриптом экспортнуть

File

File

не то, это обычный текстовый файл типа csv

уже нашел - надо было тыкать generate scripts

а экспорт это какая-то фигня

не то, это обычный текстовый файл типа csv

Но его потом тоже импортнуть можно ;)

какой секторсайз лучше для postgresql размером в 400 гб на ссд?

какой секторсайз лучше для postgresql размером в 400 гб на ссд?

4к?

какой секторсайз лучше для postgresql размером в 400 гб на ссд?

Эт смотря что делать

Интересно есть ли бонус в совпадении секторсайз файловой системы и блоксайз базы данных

вопрос: что такое сектор на ssd?

какой секторсайз лучше для postgresql размером в 400 гб на ссд?

а он там фиксирован?