✅ ابزار قدرتمند ChartDB رقیب جدی Drawdb (بسیار شبیه)

یک ویرایشگر web-based طراحی دیاگرام دیتابیس، که database schema را با یک Smart Query میتواند سریع visualize کند و خروجی SQL scripts بدهد

🔥 تمام این امکانات بدون حتی نیاز به لاگین
https://github.com/chartdb/chartdb

#Database

اگه در توسعه پروژتون نیاز به بک اند و دیتابیس داشتید، اما به هر دلیلی دسترسی به بک اند کار نداشتید و از فایربیس امثالهم خسته شدید، میتونید از ابزاری به نام Json-Server استفاده کنید و Api های مورد نیاز پروژتون رو توسعه بدید.

خب JSON Server چیه؟ 🔬

کلمه JSON مخفف عبارت JavaScript Object Notation هست و یک ابزار Node.js سبک و با کاربری آسونه که یک API RESTFUL و با استفاده از یک فایل JSON به عنوان data source شبیه‌سازی می‌کنه. توسعه‌ دهنده های فرانت‌اند با کمک JSON Server می‌تونن APIهای ساختگی و بدون نیاز به نوشتن کدهای پیچیده سمت سرور یا زمانی که API پشتیبان هنوز آماده نیست ایجاد کنن.

این API ساختگی درخواست‌ها رو به endpoint ای که تنظیم میکنید ارسال می‌کنه، به درخواست‌های HTTP پاسخ میده و به این ترتیب کار و برای توسعه سریع برای توسعه‌دهندگان ایده‌آل می‌کنه. JSON Server همچنین توسعه‌دهندگان و قادر می‌سازخ تا عملیات CRUD و انجام بدن و داده‌ها رو در فایل‌های JSON ذخیره کنند.


ویژگی‌های JSON Server 🔍

❗️راه‌اندازی آسان و سریع

❗️پشتیبانی از CRUD

❗️قدرتمند و ساده

❗️شبیه سازی داده ها


عملکرد Json server مثل یه بک‌اند واقعی هست. از این به بعد به جای استفاده از دیتابیس هایی مثل firebase که تحریم و مشکلاتی داره... میتونید از جیسون سرور برای توسعه نمونه کار هاتون استفاده کنید.
بهتون پیشنهاد میکنم نحوه نصب و استفاده رو تو داکیومنتش مطالعه کنید 💠


Document 🌐

#jsonServer #database
@CodeModule

گاها پیش میاد که بچه ها در مورد نحوه اجرای transaction دیتابیس سوال میپرسن در شرایطی که ممکنه دو قسمت یک تراکنش مربوط به دو ماژول مختلف باشه و تو ساختار کد خیلی راحت نشه این تراکنش رو اجرا کرد

این مقاله توضیحات خوبی در این مورد میده
Database Transactions in Go with Layered Architecture
https://threedots.tech/post/database-transactions-in-go

@gocasts

#golang #database #transactions

همیشه برای خودم سوال بوده که دیتابیس ها بصورت سنتی روی vm یا بصورت cloud با استفاده از docker و kubernetes چه مزایا و معایبی دارن، هم از نظر هزینه های نگهداری و هم از نظر performance و عملکرد. اگه تجربه ای دارید خوشحال میشم بشنوم.

استقرار دیتابیس روی vm با حالت dockerize شده ش خصوصا برای استارت آپ های کوچیک چه تفاوت هایی میتونه داشته باشه؟

این مقاله هم در همین مورد نکاتی میگه
https://thenewstack.io/kubernetes-for-databases-weighing-the-pros-and-cons/


توضیحات «دوره + تیمسازی بکند و گولنگ Go Casts» و تخفیف ۵۰ درصدی رو در این پست میتونید بخونید 👇
https://t.iss.one/gocasts/515

@gocasts

#database #kubernetes

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

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

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

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

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

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

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

#sql #database #db #nf

@ninja_learn_ir

دو مقاله شیک و قشنگ در مورد دیتابیس ها بصورت کلی و postgres

Things I Wished More Developers Knew About Databases
https://rakyll.medium.com/things-i-wished-more-developers-knew-about-databases-2d0178464f78


What I Wish Someone Told Me About Postgres
https://challahscript.com/what_i_wish_someone_told_me_about_postgres


@gocasts
#database

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

📢 معرفی CONN_MAX_AGE در Django

متغیر CONN_MAX_AGE یکی از تنظیمات مهم Django است که برای مدیریت اتصالات پایدار (Persistent Connections) به پایگاه داده استفاده می‌شود. این تنظیم مشخص می‌کند که یک اتصال به پایگاه داده برای چه مدت زمان زنده بماند و پس از آن بسته شود.

🔍 CONN_MAX_AGE چیست و چگونه عمل می‌کند؟

- مقدار CONN_MAX_AGE نشان‌دهنده مدت زمان (بر حسب ثانیه) است که یک اتصال به پایگاه داده در حالت باز باقی می‌ماند.
- اگر مقدار آن روی ۰ تنظیم شود، اتصال به پایگاه داده پس از هر درخواست بسته می‌شود (رفتار پیش‌فرض).
- اگر مقدار CONN_MAX_AGE روی `None` تنظیم شود، اتصال به پایگاه داده هرگز بسته نمی‌شود و دائماً زنده می‌ماند (تا زمانی که فرآیند Worker یا برنامه بسته شود).

⚙️ مقدار پیش‌فرض CONN_MAX_AGE

به صورت پیش‌فرض، مقدار CONN_MAX_AGE برابر با ۰ است. یعنی Django پس از پایان هر درخواست، اتصال به پایگاه داده را می‌بندد و برای درخواست جدید، اتصال دیگری باز می‌کند. این رفتار برای پروژه‌های کوچک یا آزمایشی مناسب است ولی در محیط تولید (Production) ممکن است باعث کاهش عملکرد شود.

✏️ نحوه تنظیم CONN_MAX_AGE

مقدار CONN_MAX_AGE در تنظیمات پایگاه داده تعریف می‌شود. مثال زیر نحوه استفاده از آن را نشان می‌دهد:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'your_database',
        'USER': 'your_user',
        'PASSWORD': 'your_password',
        'HOST': 'your_host',
        'PORT': 'your_port',
        'CONN_MAX_AGE': 600,  # 600 seconds
    }
}

✅ چند سناریو برای تنظیم CONN_MAX_AGE

1. پروژه کوچک یا محیط توسعه
- سناریو: اگر پروژه شما تعداد کمی از درخواست‌ها را مدیریت می‌کند یا در حال توسعه هستید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 0
     

- توضیح: اتصال پس از هر درخواست بسته می‌شود. این کار به شما کمک می‌کند که رفتار واقعی برنامه را در محیط توسعه مشاهده کنید.

2. پروژه با بار متوسط
- سناریو: اگر برنامه شما درخواست‌های متوسطی (نه کم، نه زیاد) دارد و پایگاه داده شما برای تعداد اتصالات زیاد محدودیت خاصی ندارد.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 300  # 5 minutes
     

- توضیح: این تنظیم باعث می‌شود که اتصالات برای چندین درخواست استفاده شوند و هزینه باز و بسته کردن اتصال کاهش یابد.

3. پروژه با بار زیاد (High Traffic)
- سناریو: اگر برنامه شما تعداد زیادی درخواست دارد و می‌خواهید عملکرد را بهینه کنید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 600  # 10 minutes
     

- توضیح: این مقدار کمک می‌کند که هزینه باز و بسته کردن مکرر اتصالات کاهش یابد، اما همچنان اتصالات پس از مدتی بسته می‌شوند تا از مشکلات احتمالی جلوگیری شود.

4. پروژه‌های با درخواست‌های خیلی کم
- سناریو: اگر برنامه شما به ندرت به پایگاه داده متصل می‌شود (مثلاً به دلیل استفاده از کش یا تعامل کم با پایگاه داده).
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 0  # each http request
     

- توضیح: نگه‌داشتن اتصال در این موارد منطقی نیست و بهتر است اتصال پس از هر درخواست بسته شود.

5. استفاده از Connection Pooling خارجی
- سناریو: اگر از ابزارهای خارجی مدیریت اتصال مانند pgbouncer (برای PostgreSQL) یا ProxySQL (برای MySQL) استفاده می‌کنید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': None
     

- توضیح: در این حالت، مدیریت اتصالات به ابزارهای خارجی سپرده شده است و Django نیازی به بستن اتصالات ندارد.

⚠️ نکات مهم:

1. مراقب تعداد اتصالات باشید:
اگر مقدار CONN_MAX_AGE را روی مقدار زیاد یا None تنظیم کنید، مطمئن شوید که سرور پایگاه داده شما می‌تواند تعداد زیادی اتصال همزمان را مدیریت کند. در غیر این صورت ممکن است با خطای "too many connections" مواجه شوید.

2. محیط production:
در محیط تولید، معمولاً مقدار CONN_MAX_AGE روی چند دقیقه (مثلاً ۵ تا ۱۰ دقیقه) تنظیم می‌شود تا عملکرد بهینه باشد و اتصالات مکرر ایجاد نشوند.

3. ابزارهای خارجی مدیریت اتصال:
اگر از Connection Pooling خارجی استفاده می‌کنید، مقدار CONN_MAX_AGE را روی None تنظیم کنید تا Django اتصال را مدیریت نکند.

conn_max_age

#database #django

@Syntax_fa

مقاله زیر به ما آموزش میده چطور 1,000,000 رکورد دیتا رو در 4 ثانیه در PostgreSQL ذخیره کنیم!

https://www.timescale.com/learn/testing-postgres-ingest-insert-vs-batch-insert-vs-copy?ref=timescale.com

#postgresql
#database

source

@Syntax_fa

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

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

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

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

خب خب خب 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

در دیتابیس مفهومه ACID چیه؟

شماره یک ( 🅰️ - Atomicity):

به این معناست که یک transaction (عملیات در دیتابیس) یا کامل انجام میشه یا اصلاً انجام نمیشه.
اگه در طول اجرای transaction خطایی رخ بده، تمام تغییرات انجام‌شده در دیتابیس باید لغو بشه (rollback) تا دیتابیس در وضعیت اولیه باقی بمونه.

📌 مثلا؟؟
فرض کنین شما در حال انتقال پول از حساب بانکیتون به حساب شخص دیگه ای هستین. اگه فرایند انتقال بطور کامل انجام بشه (یعنی پول از حساب شما کم شده و به حساب اون شخص اضافه بشه)، تراکنش موفقیت‌آمیزه.✅️

اما اگه وسطه عملیات مشکلی پیش بیاد (مثلاً اتصال اینترنت قطع بشه)، هیچ‌کدوم از این تغییرات نباید در دیتابیس باقی بمونه. یعنی یا همه عملیات‌ها باید انجام بشن، یا هیچکدوم نباید انجام بشن.
#Database
#ACID
#Atomicity

@GoldenCodeir

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

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

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

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

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

@GoldenCodeir

🔵 عنوان مقاله
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