Postgresql + Программирование

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

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

Приходится танцевать с бубном. Например, после записи я понял, что у меня был косяк с гарнитурой и звук был фиговый. Пришлось на имеющийся видеоряд с записью экрана накладывать новый аудио-видео ряд с голосом и миниатюрной головой. Это вылилось в адок на монтаже, общее время монтажа 17-минутного ролика составило часов 15. Всё для вас, дорогие будущие зрители :)

Спасибо за поддержку, буду рад новым подпискам на канал и идеям по развитию!

Ну и немного внутренней кухни:

Ролик, протяженностью 20 минут (после монтажа) я записываю где-то час. Монтаж ролика занимает у меня примерно 6 часов. Это удаление пауз, эээканья, неудачных фраз, которые потом перезаписываю, работа со скоростью видео и прочее.

И примерно 30-40 минут уходит на оформление ролика в ютубе и рисование превью.

Задавайте вопросы, с радостью отвечу! Критику тоже приму с радостью, только не закидывайте уж очень сильно тапками, пожалуйста :)

Пост без рейтинга.

Здравствуйте, друзья!

Готовы порешать SQL-задачи на тему псевдостолбцов? Что такое псевдостолбцы и примеры их использования можно почитать тут.

Эти и другие задачи с собеседования опубликованы в нашем Телеграм-канале.

Итак, задача номер 1:

В таблице TEMP_TABLE один столбец и пять строк.
Запрос SELECT 1 FROM TEMP_TABLE

а) выведет данные из первого столбца для всех строк;

б) выведет просто цифру 1;

в) выведет пять строк, в каждой из которых будет цифра 1;

г) выдаст ошибку.

Здесь нужно поставить чтение на паузу и выбрать правильный вариант ответа.
На сегодня разброс ответов на задачу такой (правильный ответ в зелёном цвете):

Объяснение: данный в задаче запрос выводит данные из таблицы TEMP_TABLE (так как SELECT..FROM TEMP_TABLE), поэтому будут выводиться строки из неё (все сколько есть). Но в блоке SELECT не указан ни один из (настоящих) столбцов таблицы. Не выбираются данные из какого-либо столбца.
В нашем примере указано что пока выводятся строки из таблицы TEMP_TABLE нужно выводить цифру 1, а не показывать данные какого-либо столбца.

Задача 2:
Дана следующая таблица TEST_TABLE с тремя строками:
SELECT * FROM TEST_TABLE
ID  NAME
1  NULL
2  NULL
3  NULL
Каков будет результат следующего запроса: SELECT SUM(1) FROM TEST_TABLE?

Здесь опять нужно поставить чтение на паузу и написать правильный вариант ответа. На сегодня разброс ответов на задачу такой (правильный ответ в зелёном цвете):

Объяснение: здесь тоже речь идёт о псевдостолбце. Пока выводятся данные из TEST_TABLE блок SELECT выводит единицу, а не какой-либо реальный столбец таблицы. Пока не смотрите на функцию SUM. Итого единица выведется три раза (по количеству строк в таблице). И вот теперь, с помощью функции SUM получим сумму всех введённых чисел (единичек), то есть число 3.

Ещё больше SQL-задач с собеседований и реальной практики в разных СУБД в нашем Телеграм-канале.

Заходи на наш Youtube-канал и найдёшь много интересного и полезного про базы данных и язык SQL.

Кажется всё просто. Но есть ряд вопросов.

1. А что, собственно, собой представляет объект conn? Имеется ввиду, что происходит на стороне базы, когда запрашивается соединение? Производится какая-то запись куда-то? Как это выглядит?

2. Почему объект conn нельзя десериализовать, чтобы передавать его между процессами в мультипроцессинге?

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

4. А если твой код выглядит примерно так (ниже). Т.е. в бесконечном цикле в отдельном процессе выполняется функция, тогда как закрывать соединение? Когда? А что будет, если программа вылетит?

   def функция(параметры):

   conn = psycopg2.connect(паратметры)

   cursor = conn.cursor()

   while True:

   cursor .execute(запрос)

   conn.commit()

   time.sleep(2)

   if __name__ == "__main__":

   mp_take_proxy_us_proxy_org = mp.Process(target=Фнукция, kwargs={параметры}, )
   

Вот пока вроде и весь пул вопросов. Подскажите, пожалуйста.

Проверял 3 БД: MySQL сдвижками InnoDB и MyISAM, SQLite и Postgres. Написал скрипт, который эмулирует заполнение БД и запросы к ней, и измеряет сколько времени занимает добавление записи и выполнение запроса. Скачать скриптец можно тут (он сугубо тестовый, т.е. стрёмный и без никакой обработки ошибок, уж сорян). Менял количество пользователей и количество записей у каждого пользователя и смотрел что будет если всё писать в одну таблицу, либо каждому пользователю создавать отдельную. Заодно после выполнения скрипта посмотрел сколько полученные базы данных занимают места на диске.
И вот получились такие таблички.

Какие выводы я для себя сделал.

Во первых видно, что если делать по таблице для каждого пользователя, то и добавление записи, и обработка запроса и размер БД получаются вобщем не лучше, чем если завести одну таблицу на всех. Единственное исключение – выполнение запросов в SQLite (и в некоторых случаях для Postgre) может быть в разы быстрее на многих таблицах, чем на одной. Почему так получается? Думаю потому что БД люто заоптимизированы очень крутыми чуваками под определенные сценарии использования. И если ты не столь-же крут (я лично нет), то нужно выбрать наиболее подходящую БД и подгонять свою задачу под типичные сценарии использования этой БД.

Во вторых если мне важнее скорость добавления/чтения (т.е. экономить вычислительные ресурсы) то из протестированных лучше пользовать Postgres, если важнее экономить место на диске – то MySQL с движком MyISAM. MySQL с движком InnoDB где-то посередине.

В третьих SQLite неожиданно всех обошел в скорости выполнения запросов (для моего случая по крайней мере). Прикольно.

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

В любом случае это было интересно сделать, надеюсь кому-то было интересно и почитать.

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

Моя таблица сформирована вот так:

-- Table: public.employee
-- DR OP TABLE IF EXISTS public.employee;
CRE ATE TABLE IF NOT EXISTS public.employee
(
id BIGINT NOT NULL DEFAULT NEXTVAL('employee_id_seq'::regclass),
first_name CHARACTER VARYING(50) COLLATE pg_catalog."default" NOT NULL,
last_name CHARACTER VARYING(50) COLLATE pg_catalog."default" NOT NULL,
gender CHARACTER VARYING(6) COLLATE pg_catalog."default" NOT NULL,
email CHARACTER VARYING(150) COLLATE pg_catalog."default",
date_of_birth DATE NOT NULL,
country_of_birth CHARACTER VARYING(50) COLLATE pg_catalog."default" NOT NULL,
CONSTRAINT employee_pkey PRIMARY KEY (id)
)
TABLESPACE pg_default;

В вот данные: https://transfiles.ru/1gt3q