SQLite is not a toy database

https://antonz.org/sqlite-is-not-a-toy-database

Personally, I find sqlite to be very convenient. Being simple and serverless, supported by your favorite ORM and easy to setup just contributes to this quality.

#sql #sqlite

اگه دنبال برنامه ای هستید که توش sql بنویسید و تست کنید MySql Workbench میتونه نیازتون رو برطرف کنه

محیط ساده ای داره
و امکانات خوبی برای مدیریت mysql بهتون میده

من خودم فقط برای تست sql ازش استفاده میکنم اگه از امکانات دیگه‌اش که کارتون رو اسون تر میکنه استفاده میکنید میتونید تو کامنتا بگید

#sql #mysql
@CleverDevs - @CleverDevsGp

💎 اصول Normalization در طراحی دیتابیس 💎

امروز می‌خوام در مورد یکی از مهم‌ترین اصول طراحی دیتابیس یعنی "نرمال‌سازی" صحبت کنم. اگه می‌خواین دیتابیس‌تون پر سرعت و بدون مشکل کار کنه، باید با این سه فرم اصلی نرمال‌سازی آشنا بشین.

1⃣ فرم اول نرمال (1NF)
تو فرم اول نرمال، باید همه‌ی ستون‌های دیتابیس‌تون "اتمی" باشن. یعنی هر سلول از جدول باید فقط یه مقدار داشته باشه، نه چندتا مقدار!
📌 مثال:
فرض کن یه جدول داری که توش شماره تلفن‌های چند نفر رو ذخیره کردی. اگه تو یه سلول چند تا شماره تلفن ذخیره کنی، دیتابیست تو فرم اول نرمال نیست باید هر شماره تلفن توی یه ردیف جدا باشه.

2⃣ فرم دوم نرمال (2NF)
وقتی فرم اول رو رعایت کردی، می‌رسی به فرم دوم. تو این فرم، باید مطمئن بشی که همه‌ی ستون‌های غیرکلیدی، وابسته به کلید اصلی (Primary Key) باشن.
📌 مثال:
فرض کن یه جدول داری که اطلاعات دانش‌آموزان و درس‌هایی که می‌خونن رو ذخیره می‌کنه. اگه یه ستون مربوط به اطلاعات کلاس (مثل شماره کلاس) باشه که وابسته به دانش‌آموز نباشه، دیتابیس‌ت تو فرم دوم نرمال نیست. باید اون اطلاعات رو تو یه جدول جدا ذخیره کنی.

3⃣ فرم سوم نرمال (3NF)
حالا که فرم دوم رو رعایت کردی، می‌رسیم به فرم سوم. اینجا باید مطمئن بشی که هیچ ستون غیرکلیدی به یه ستون غیرکلیدی دیگه وابسته نباشه
📌 مثال:
اگه تو جدول دانش‌آموزان، هم اسم شهر و هم اسم استان رو ذخیره کنی و استان وابسته به شهر باشه، دیتابیس تو فرم سوم نرمال نیست. باید شهر و استان رو تو یه جدول دیگه ذخیره کنی.

جمع بندی 🎯
این سه فرم نرمال‌سازی باعث می‌شن دیتابیس‌تون بهینه‌تر باشه، خطاهای کمتری داشته باشه و به راحتی قابل توسعه باشه. پس اگه می‌خواین دیتابیس‌تون تو پروژه‌های بزرگ دچار مشکل نشه، حتما این اصول رو رعایت کنین 😉

امید وارم مفید بوده باشه :)

#sql #database #db #nf

@ninja_learn_ir

💎 چطوری مشکلات Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock رو هندل کنیم؟ 💎

توی پست قبلی درباره چند تا مشکل مثل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock حرف زدیم. امروز می‌خوایم ببینیم چطوری می‌تونیم اینا رو توی برنامه‌مون هندل کنیم. اینا مشکلاتیه که می‌تونن عملکرد دیتابیس و اپلیکیشن رو خراب کنن، ولی با استفاده از تکنیک‌های کنترل همزمانی و ایزولیشن می‌شه جلوی اینا رو گرفت.



1⃣ Dirty Read 💾

برای جلوگیری از Dirty Read، باید از سطح ایزولیشن مناسبی استفاده کنیم. یکی از بهترین سطوح ایزولیشن برای این کار Read Committed هست. این سطح تضمین می‌کنه که فقط داده‌های commit شده قابل خوندن هستن.

مثال:
فرض کن توی دیتابیستون از سطح ایزولیشن Read Committed استفاده می‌کنی. اگه تراکنش A داره داده‌هایی رو آپدیت می‌کنه، تراکنش B تا وقتی که A کارش تموم نشده و داده‌ها رو commit نکرده، نمی‌تونه اون داده‌ها رو ببینه. پس از Dirty Read جلوگیری می‌شه.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

2⃣ Non-Repeatable Read 🔄

برای جلوگیری از Non-Repeatable Read، باید سطح ایزولیشن رو به Repeatable Read تغییر بدیم. این سطح ایزولیشن تضمین می‌کنه که اگر یک بار داده‌ای رو توی تراکنش خوندیم، تا پایان تراکنش دیگه تغییر نمی‌کنه.

مثال:
فرض کن توی یه فروشگاه آنلاین، وقتی یه کاربر قیمت یه محصول رو چک می‌کنه، باید مطمئن بشی که اون قیمت تا پایان تراکنش تغییر نمی‌کنه. با استفاده از Repeatable Read، هر چی کاربر دید، همون می‌مونه.

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

3⃣ Phantom Read 👻

برای حل مشکل Phantom Read باید از سطح ایزولیشن Serializable استفاده کنیم. این سطح از ایزولیشن باعث می‌شه که نه تنها داده‌های موجود، بلکه هر داده جدیدی هم تا پایان تراکنش دیده نشه.

مثال:
فرض کن یه مدیر داره گزارش تعداد کارمندای یه بخش رو چک می‌کنه. با سطح ایزولیشن Serializable، اگر کارمند جدیدی در طول تراکنش اضافه بشه، مدیر اون رو تا پایان تراکنش نمی‌بینه و از Phantom Read جلوگیری می‌شه.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

4⃣ Deadlock 🔐

برای هندل کردن Deadlock، چند راه وجود داره:

1⃣ اجتناب از قفل‌های طولانی:
تراکنش‌ها رو سبک و سریع نگه دار تا قفل‌های طولانی ایجاد نشن.

2⃣ ترتیب دسترسی یکسان:
مطمئن شو که تراکنش‌ها به منابع به یه ترتیب دسترسی پیدا می‌کنن. یعنی اگر A و B هر دو به رکوردهای ۱ و ۲ نیاز دارن، هر دو اول رکورد ۱ رو قفل کنن و بعد برن سراغ رکورد ۲.

3⃣ زمان‌بندی دوباره تراکنش‌ها:
می‌تونی از دیتابیس بخوای که اگه Deadlock تشخیص داد، یکی از تراکنش‌ها رو ریست کنه و دوباره اجرا کنه.

مثال:
فرض کن توی اپلیکیشن مالی‌ات دو تراکنش همزمان دارن از منابع یکسان استفاده می‌کنن. یکی از راه‌های جلوگیری از Deadlock اینه که مطمئن بشی تراکنش‌ها به یه ترتیب مشخص به منابع دسترسی دارن، مثلاً اول رکورد ۱ رو قفل می‌گیرن و بعد رکورد ۲.

BEGIN TRANSACTION;
-- Lock resources in the same order

جمع‌بندی 🎯

با استفاده از سطوح ایزولیشن و یه سری تکنیک‌های مدیریت تراکنش، می‌تونیم مشکلاتی مثل Dirty Read، Non-Repeatable Read، Phantom Read و Deadlock رو توی دیتابیس‌هامون حل کنیم. اگر این نکات رو توی اپلیکیشن‌هاتون رعایت کنید، کارتون خیلی راحت‌تر و پایدارتر می‌شه.

امید وارم مفید بوده باشه :)

#sql #dead_lock #programing

@ninja_learn_ir

A comprehensive guide to writing clear, consistent, and professional SQL code. It provides detailed recommendations for naming conventions, formatting, and best practices, ensuring code readability and maintainability.
راهنمایی جامع برای نوشتن کدهای SQL واضح منسجم و حرفه‌ای. این سایت توصیه‌هایی در مورد شیوه‌های نام‌گذاری، قالب‌بندی و بهترین شیوه‌ها ارائه می‌دهد تا کدهای شما خوانا و maintainable باشند.

#SQL #Database #CodingStandards #BestPractices
@pythony

https://sqlstyle.guide

GenAI can be great for this one.

#ai #sql

یه چیت شیت خوب واسه sql و css
خلاصه که عشق کنید😁

توو منبع اصلیش(لینک اخر) چیت شیتای بیشتری گذاشته، پیشنهاد میکنم بررسی کنین
#css
#sql
@GoldenCodeir

(منبع👇🏾)
https://x.com/swapnakpanda/status/1867820437310218716?s=19

پیشنهاد میکنم یه گوشه کنار داشته باشیدش که لازمتون میشه

(برگ تقلب SQL - JOIN)
#SQL
@GoldenCodeir

https://x.com/denicmarko/status/1876955314009858322?t=xSdqa7O7oRbJeF0AlfSuSA&s=35

لینکهای فراگیری Javascript

   علاوه بر اینکه در یک پُست هشتگ های کانال رو معرفی کرده ام، حالا لینکهایی از مطالب مربوط جاوااسکریپت رو هم براتون میذارم که دوره کنید:

- کار با Local storage دیتابیس داخلی
- مشکلات محاسباتی در جاوااسکریپت
- روش ساخت برنامه تست چند جوابی
- چهار فرآیند CRUD در جاوااسکریپت
- آموزش Typescript یا جاوااسکریپت۶
- یک برنامه ی محاسباتی جاوااسکریپت
- جزوه ی مدرن جاوااسکریپت فارسی
- قفل گذاری روی برنامه ی تحت وب
- جزوه ی نصب و آموزش Node.js
- روش ساخت اَپ تک صفحه در Vue.js
- روش ساخت تاس با ۵ خط کدنویسی

علاوه بر اینها روی هشتگ زیر بزنید:
#javascript

#MP4 #Video #SQL_Injection
🎥 آموزش تصویری تکنیک بهره بردن از آسیب پذیری تزریق کد SQL به اجرای کد به صورت ریمورت
➖➖➖➖➖
🆔 @PenetrationTest

🍁 كد نويسي نمونه ابزار تست نفوذ آسيب پذيري Sql Injection

در اين ويديو يك ابزار براي نمونه جهت تست آسيب پذيري Sql Injection بر روي وبسايت تحت لينوكس كدنويسي ميكنيم..

🌷 آموزش در پست بعدي قابل دانلود ميباشد
➖➖➖➖➖➖➖➖➖➖
#sql #injection #pentest
Author:4TT4CK3R
🔱 برترين كانال امنيت در ايران
@FullSecurity

#Bug #SQL

📽 آموزش تصویری نفوذ به پنل های جوملا از طریق حفره امنیتی در کامپوننت Tag

نوع باگ : SQL Injection
➖➖➖➖➖➖➖
🎩 @PenetrationTest

#Kali #Hack #SQL

📽 آموزش تصویری ابزار Jsql در کالی لینوکس برای انجام حملات دیتابیس هکینگ
🆔 @PenetrationTest

خب خب خب ORM چیه ؟ 🛸

امروز می‌خوام درباره‌ی یه موضوع مهم و کاربردی تو دنیای برنامه‌نویسی حرف بزنم: ORM یا همون Object-Relational Mapping.

‏🧠 ORM یعنی چی؟

‏ORM (Object-Relational Mapping) یه تکنیک تو برنامه‌نویسیه که داده‌های دیتابیس رو به شکل اشیاء (objects) تو زبون‌های شی‌گرا مثل پایتون، جاوا یا سی‌شارپ مدیریت می‌کنه. به بیان ساده، ORM یه پل ارتباطی بین دنیای شی‌گرایی (کلاس‌ها و اشیاء) و دنیای دیتابیس‌های رابطه‌ای (جداول و ستون‌ها) می‌سازه. با ORM دیگه لازم نیست مستقیم با کوئری‌های SQL کار کنی؛ در عوض، با همون زبون برنامه‌نویسی‌ات دیتابیس رو کنترل می‌کنی.

مثلاً به جای اینکه بنویسی:

SELECT * FROM users

می‌تونی تو پایتون با Django ORM اینجوری بنویسی:

users = User.objects.all()

و همون نتیجه رو بگیری

‏📚 ORM چطوری کار می‌کنه؟
فرض کن تو دیتابیست یه جدول به اسم users داری که ستون‌هاش اینان:

id، name و email

تو برنامه‌ات یه کلاس به اسم User می‌سازی که پراپرتی‌هایی مثل id، name و email داره. ORM این کلاس رو به جدول users توی دیتابیس مپ (map) می‌کنه. یعنی هر شیء از کلاس User نمایانگر یه رکورد تو جدول users می‌شه.

چند تا سناریو رو با هم ببینیم:

1⃣ ذخیره کردن داده:
یه شیء از کلاس User می‌سازی، مقادیرش رو پر می‌کنی و با یه متد مثل save() ذخیره‌اش می‌کنی. ORM این کار رو به یه دستور SQL (مثل INSERT) تبدیل می‌کنه و اجرا می‌کنه.

user = User(name='علی', email='[email protected]')
   user.save()
  

2⃣ خوندن داده:
میتونی به جای کوئری SQL، از متدهایی مثل all() یا filter() استفاده می‌کنی. ORM پشت صحنه کوئری مناسب رو می‌سازه و داده‌ها رو به شکل اشیاء برمی‌گردونه.

   # همه کاربرها
users = User.objects.all()

   # فیلتر کردن
ali_users =
User.objects.filter(name='علی')

به همین سادگی ORM تمام پیچیدگی‌های کار با دیتابیس رو از دید تو مخفی می‌کنه و یه رابط کاربری راحت بهت می‌ده.

البته هر orm با orm های دیگه فرق داره هرچی یه orm بیشتر abstraction انجام داده باشه استفاده ازش راحت تر میشه
ولی توی مقیاس بالاتر همین سادگی باعث پیچیدگی میشه.

‏🚀 ORM برای چی به وجود اومد؟

قبل از اینکه ORMها باشن، برنامه‌نویس‌ها مستقیم با SQL کار می‌کردن. (هرچند همین الانشم توی زبان های هایی که orm مناسبی براش ساخته نشده برنامه نویسان بصورت خام کد sql میزنن مثل برنامه نویسان golang)

این چند تا مشکل داشت و داره:

کدهای طولانی:
برای هر عملیات ساده، باید یه کوئری SQL می‌نوشتی که گاهی خیلی پیچیده می‌شد.

خطای زیاد:
یه اشتباه کوچیک تو کوئری (مثل یه typo) می‌تونست ساعت‌ها وقتت رو تلف کنه.

سختی نگهداری:
اگه ساختار دیتابیست عوض می‌شد (مثلاً یه ستون اضافه یا کم می‌شد)، باید همه کوئری‌ها رو دستی تغییر می‌دادی.

تفاوت پارادایم:
‏ SQL یه زبون declarative (اعلانی) هست، ولی زبون‌هایی مثل پایتون imperative (دستوری) هستن. این یعنی برنامه‌نویس باید مدام بین دو مدل فکری جابه‌جا می‌شد.

‏ORM اومد که این مشکلات رو حل کنه:

سادگی:
کار با دیتابیس مثل کار با اشیاء تو زبون خودت می‌شه.

امنیت:
‏ORMها معمولاً جلوی حملاتی مثل SQL Injection رو می‌گیرن.

انعطاف‌پذیری:
می‌تونی دیتابیس رو عوض کنی (مثلاً از MySQL بری به PostgreSQL) بدون اینکه کل کدت رو تغییر بدی.

سرعت توسعه:
چون کوئری‌نویسی کمتر می‌شه، وقت بیشتری برای منطق اصلی برنامه‌ات داری.

جمع‌بندی ✍
‏ORM یه ابزار باحال و قدرتمنده که کار با دیتابیس رو برای برنامه‌نویس‌ها راحت‌تر، سریع‌تر و امن‌تر می‌کنه. با ORM دیگه لازم نیست با SQL خام کلنجار بری و می‌تونی با همون زبون برنامه‌نویسی‌ات همه‌چیز رو مدیریت کنی.

#️⃣ #database #sql #orm

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

وقتی از دستور "%LIKE "%fo برای جستجو استفاده می‌کنیم، درین شرایط دیتابیس باید تمام اطلاعات رو برامون بررسی کنه که خب باعث میشه سرعت پایین بیاد. راه بهتر برای جستجوی سریعتر استفاده از full-text هستش.

این روش کمک میکنه تا دیتابیس خیلی سریع‌تر و کارآمدتر فرایند جستجو رو انجام بده.
(طریقه استفادش در تصویر درج شده)
#SQL
#PHP
@GoldenCodeir
(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1902014134561947783?t=jHjPbh6DAmevpRPeQSCDWg&s=35

اگر یک query در دیتابیس کند باشه، می‌تونیم از دستور EXPLAIN استفاده کنیم تا بفهمیم مثلا چطوری یک سرچ یا فیلتر اجرا میشه.
اگه در خروجی EXPLAIN دیدید که 'access type' برابر با ALL هست، یعنی دیتابیس همه‌ی رکوردهای جدول رو داره بررسی میکنه که باعث کندی میشه. درین صورت باید از index استفاده کنیم تا سرعت query بیشتر بشه.

حالا چجوری ازش استفاده کنیم؟

EXPLAIN SELECT * FROM users WHERE age > 30;

#sql
@GoldenCodeir

(به‌منبع دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1904174361642205309?t=rdYfmiptB7CN_obg0VDafg&s=19

خب حالا بریم سراغ C یا همون Consistency(سازگاری) در ACID:

ویژگی Consistency در دیتابیس یعنی بعد از انجام هر transaction، دیتاهامون باید همیشه صحیح و درست باقی بمونن. یعنی دیتابیس نباید هیچ وقت به وضعیتی نادرست یا اشتباه برسه.

📌 اگه transaction ها قوانین دیتابیس رو رعایت نکنن (مثلاً مقدار موجودی کافی نباشه)، سیستم اونا رو رد میکنه و هیچ تغییری روی داده‌ها اعمال نمیشه.
پس یعنی بعد از هر تغییر در دیتابیس، سیستم باید مطمئن بشه که همه‌چیز درست و منطبق با قوانین دیتابیس هستش.

فرض کنین شما در یک فروشگاه آنلاین قصد خرید یک کالای خاص رو دارید. وقتی وارد سایت میشن و کالای مورد نظر رو به سبد خرید اضافه میکنید، سیستم باید بررسی کنه که آیا موجودی اون کالا کافیه یا نه.
اگه موجودی کالا تموم شده باشه، سیستم اجازه خرید رو به شما نمیده و از انجام تراکنش جلوگیری میکنه.

این نشون دهنده Consistency است که سیستم همیشه دیتاهای صحیح و قابل اعتماد رو حفظ میکنه.👌🏾
#ACID
#SQL
#Database

@GoldenCodeir

نکته مهم برای کوئری‌های MySQL

اگه روی یک ستون دیتابیس ایندکس تعریف شده، استفاده از توابعی مثل YEAR(), MONTH() یا هر تابع دیگه ای روی همون ستون در شرط‌های WHERE باعث میشه MySQL نتونه از ایندکس استفاده کنه.

📌 چرا؟

چون وقتی تابعی روی ستون اعمال میشه، مقدار ستون تغییر میکنه و ایندکس روی مقدار اصلی ستونه، نه مقدار تبدیل‌شده توسط تابع.
در نتیجه MySQL مجبور میشه کل جدول رو اسکن کنه (Full Table Scan) که عملکرد کوئری رو به شدت کاهش میده.

مثال

فرض کنین روی ستون تاریخ paid_at ایندکس دارید و میخواید رکوردهای مربوط به سال 2023 رو بگیرید.

روش اشتباه:

WHERE YEAR(paid_at) = 2023

درین حالت، MySQL برای هر ردیف ابتدا تابع YEAR() رو اجرا میکنه و سپس مقایسه میکنه، که باعث غیرفعال شدن ایندکس میشه.

روش بهینه:

WHERE paid_at >= '2023-01-01' AND paid_at < '2024-01-01'

درین حالت شرط مستقیماً روی ستون paid_at اعمال میشه و MySQL میتونه از ایندکس استفاده کنه، بنابرین کوئری بسیار سریعتر اجرا میشود.
#SQL
#MySql

@GoldenCodeir

(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1952704402038333586?s=35

🔵 عنوان مقاله
Observe Live SQL Queries in Go with DTrace

🟢 خلاصه مقاله:
این مطلب از Golang Weekly نشان می‌دهد چطور با استفاده از DTrace بدون تغییر کد و توقف سرویس، کوئری‌های SQL را در برنامه‌های Go به‌صورت زنده مشاهده کنیم. نویسنده با معرفی کوتاهی از DTrace به‌عنوان یک ابزار ردیابی پویا و کم‌سربار، قدم‌به‌قدم نحوه راه‌اندازی روی سیستم‌عامل‌های پشتیبانی‌شده، اتصال به پردازه در حال اجرا و نوشتن اسکریپت‌های ساده برای دیدن متن کوئری، زمان اجرا و الگوهای فراوانی را توضیح می‌دهد؛ همراه با فیلترگذاری برای محدود کردن خروجی به سرویس/کاربر/درایور موردنظر و نکاتی برای حفظ سربار کم.

کاربرد این روش، عیب‌یابی سریع مسائلی مثل کوئری‌های کند، الگوهای N+1، شاخص‌های مفقود و ORM پرحرف در شرایط واقعی تولید است. این رویکرد مکمل لاگ‌ها و APM است و امکان تشخیص فوری و تأیید سریع اصلاحات را می‌دهد. در بخش ملاحظات، به تفاوت پشتیبانی پلتفرم‌ها (مثل FreeBSD و برخی نسخه‌های macOS؛ و پیشنهاد eBPF روی Linux)، نیاز به دسترسی‌های بالا، حساسیت داده‌های متنی کوئری و ضرورت سنجش سربار در محیط staging اشاره می‌شود.

#Go #DTrace #SQL #Observability #Performance #GolangWeekly #eBPF #Database

🟣لینک مقاله:
https://golangweekly.com/link/174425/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Did You Know Postgres Tables are Limited to 1,600 Columns?

🟢 خلاصه مقاله:
اگر نمی‌دانستید، در Postgres هر جدول حداکثر ۱۶۰۰ ستون می‌تواند داشته باشد. این یک محدودیت سخت در هسته سیستم است و با NULL بودن فیلدها یا TOAST دور زده نمی‌شود. اگر شماره issue 226 در سال 2017 را خوانده باشید، احتمالاً این نکته را به خاطر دارید. این سقف به معنای آن است که طراحی‌هایی با جدول‌های بسیار عریض—مثل هر شاخص یک ستون یا طرح‌های EAV تثبیت‌شده—به‌سرعت به حد می‌خورند. راه‌حل‌های بهتر شامل نرمال‌سازی، تفکیک عمودی، تبدیل ستون‌ها به سطرها برای سنجه‌ها، یا استفاده از JSONB برای ویژگی‌های کم‌استفاده و پراکنده است. جدول‌های خیلی عریض علاوه بر ریسک رسیدن به سقف، هزینه I/O و نگهداری را بالا می‌برند. نتیجه عملی: با در نظر گرفتن حد ۱۶۰۰ ستون، از طرح‌های باریک‌تر و انعطاف‌پذیرتر استفاده کنید و قبل از اعمال مهاجرت‌ها، تعداد ستون‌ها را بررسی کنید.

#Postgres #PostgreSQL #SQL #DatabaseDesign #DataModeling #SchemaDesign #JSONB #SoftwareEngineering

🟣لینک مقاله:
https://postgresweekly.com/link/176989/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy