Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام Data Science. SQL hub
تُعد قناة Data Science. SQL hub (@sqlhub) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 36 066 مشتركاً، محتلاً المرتبة 3 722 في فئة التكنولوجيات والتطبيقات والمرتبة 17 593 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 36 066 مشتركاً.
بحسب آخر البيانات بتاريخ 02 نوفمبر, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 122، وفي آخر 24 ساعة بمقدار -6، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 9.02%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 3.90% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 3 255 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 408 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 7.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل sql, индекс, postgres, index, sqlite.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 03 نوفمبر, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
Number Item ------------ 202 Book 202 Cartoon 202 Book 207 Book 205 Elephant 207 Elephant 208 Book 209 Biggy 209 Smoke 203 SmokeНужно сгруппировать по
number и вывести уникальные item для него, наподобие:
202 Book Cartoon 207 Book Elephant 205 Elephant 208 Book 209 Biggy Smoke 203 SmokeКак это можно сделать? ▶️В целом ничего сложного, с этим справится вот такой запрос:
SELECT Number,
group_concat (DISTINCT Item separator ' ')
FROM TABLE
GROUP BY Number
@sqlhubpg_profile/pgpro_pwr — собственно, об этом и идёт речь в видео.
Спикер рассказывает об архитектуре, возможностях, особенностях работы и способах применения этих расширений.
⏩Видео будет интересено всем, кто работает с СУБД Postgres — администраторам баз данных, инженерам нагрузочного тестирования и разработчикам приложений, непосредственно взаимодействующих с базами данных Postgres.
Enjoy)
📎 YouTube
📎 Презентация
@sqlhub/contrib/. Во-вторых, pg_proc.dat является удобной точкой входа для изучения внутренностей PostgreSQL. Также файл бывает полезен, когда вы примерно понимаете, какую функцию ищите, но не знаете ее название.
📎 Статья
@sqlhubSELECT *
FROM table
WHERE property IN ('a','b','c')
или вот этот:
SELECT *
FROM table
WHERE property='a' OR property='b' OR property='c'
▶️Если говорить про абстрактный SQL - никакой разницы нет. Есть много способов попросить достать одни и те же данные. Впрочем, с точки зрения читаемости человеком in явно выигрывает из-за компактности.
А если рассматривать конкретные реализации - то различия могут быть. Например, postgresql строит разные планы для IN и OR:
explain select * from bigtable where id = 1 or id = 3 or id=4;
QUERY PLAN
----------------------------------
Bitmap Heap Scan on bigtable (cost=13.34..25.34 rows=3 width=12)
Recheck Cond: ((id = 1) OR (id = 3) OR (id = 4))
-> BitmapOr (cost=13.34..13.34 rows=3 width=0)
-> Bitmap Index Scan on bigtable_pkey (cost=0.00..4.45 rows=1 width=0)
Index Cond: (id = 1)
-> Bitmap Index Scan on bigtable_pkey (cost=0.00..4.45 rows=1 width=0)
Index Cond: (id = 3)
-> Bitmap Index Scan on bigtable_pkey (cost=0.00..4.45 rows=1 width=0)
Index Cond: (id = 4)
explain select * from bigtable where id in (1,3,4);
QUERY PLAN
----------------------------------
Index Scan using bigtable_pkey on bigtable (cost=0.44..17.37 rows=3 width=12)
Index Cond: (id = ANY ('{1,3,4}'::integer[]))
Как можно заметить, IN был переписан в другую форму и оценён дешевле, чем несколько эквивалентных OR.
Какие-то другие СУБД может быть переписывают оба запроса в идентичное представление, или же переписывают IN в группу OR. Вопросы производительности необходимо рассматривать только в рамках какой-то конкретной реализации.
Вот такие дела
@sqlhubdev/test/prod) и даже на пустой БД, где нет данных (бэкап структуры без данных)
⏩затраты ресурсов зависят только от количества объектов в БД и количества проверок, а не от объема данных или качества приближения тестовых данных и запросов к реальным
⏩статический анализ может быть встроен в CI как элемент повышения качества разработки
Встраивать такого рода проверки в CI — это однозначно полезная практика. Разовая инвестиция в настройку конвейера исключит спектр потенциальных проблем с расхождением данных.
Подробнее об этом тут:
📎 Статья
@sqlhub
heroku pg:backups:capture && heroku pg:backups:download
2️⃣Преобразуйте загруженный файл в SQL-формат с помощью pg_restore:
pg_restore -f mydb.sql latest.dump
Здесь mydb.sql — это конечный файл с вашими данными. До начала работы убедитесь, что у вас установлен Postgres для использования команды pg_restore.
🔘Вот в принципе и всё, больше деталей и похожих кейсов тут
@sqlhub