Печально

Но, спасибо, за информацию)

Чего это... Information schema есть везде плюс dynamic sql..

Хорошо, не через жопу нет

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

Ну ты её можешь не указывать, но по факту же скрипт как-то закодирован, имеет кодировку определенную, вот её тебе и надо указывать при заливке.

Консоль в винде в cp866, если у тебя скрипт в utf-8, тебе надо его указать как исходный, но вывод если он вдруг будет на utf-8 консоль тебе правильно не покажет

Надо для этого переключить еёв решим юникода, в utf-8 , это в винде страница 65001 , но она не во всех версиях винды поддерживается.

Да нет, наоборот, радостно!

Приветствую! Вопрос скорее смежный. Есть самописный сервер, есть БД. Где лучше реализовывать бизнес-логику? Если на сервере то получается много маленьких запросов к БД. Если в БД то получаются длиннющие селекты с подселектами и джоинами.

vds-ка дохленькая, на паре ядер. Как правильнее?

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

Giving feedback

Offer alternative implementations, but assume the author has already considered them ("What do you think about using a custom validator here?").
Etki: "когда предлагаешь альтернативу, всегда предполагай, что автор вопроса конченый дятел"\

Ask questions rather than make demands/commands. Engage in conversation: "What do you think about ?", "Did you consider...?", "Can you clarify...?".

Offer compliments in code lines when you learn something new or something is done well.

Don't say "Why didn't you just...?" "just", "simply", "easily" don't give good feels. Don't use them when asking questions.

Avoid selective ownership of code ("mine", "not mine", "yours").

Be explicit. Remember people don't always understand your intentions online.

Don't use hyperbole ("always", "never", "endlessly", "nothing").

Don't use sarcasm.

я уже года 2 не делаю даже в пет проектах на 1 сервере бд и веб-сервер

если есть всего 2 ядра, то я бы посадил на разные машины веб сервер и бд по 1 ядру каждому.
когда нагрузка вырастет, то я бы сделал master/slave репликацию, добавил 1 машину отдельную, с которой можно только читать, но не записывать

куча запросов. так и надо. качай индексы и знания классических алгоритмов.
индекс как правило это бинарное дерево, которое имеет время на чтение lg n, бла-бла
...индексы сокращают время запросов

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

Много маленьких запросов к СУБД - это плохо. Но может нивелироваться хорошим сетевым каналом между хостами.
Длиннющие select-ы - это вовсе не обязательно что-то плохое, как правило, в объемных по размеру кода запросах ничего плохого нет.
Надо только уметь их писать.
Также, как правило, язык СУБД более высокого уровня и лучше приспособлен для работы с данными, со всеми типами данных, что хранятся.

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

И хотя я лично очень ЗА реализацию BL внутри БД, я бы призвал вдумчиво подходить к этому вопросу, и в идеале сочетать два подхода, реализовывать BL как в БД , так и на сервере приложения. Главное - не в UI.

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

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

Поэтому и получается такое дерьмо типа "возьмём заказ и пройдемся циклом чтобы заполнить в нем цену которая динамически считается от доп.услуг"

А почему много маленьких запросов к СУБД - это дефолтно плохо?

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

мобильное приложение в 80% случаев будет работать через lte/3g.

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

Это абсолютно точно дерьмо

я извиняюсь, что такое "пет проект"?

есть orm, который принято использовать для CRUD задач, то есть примитвных запросов.

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