CodeCrafters

Ir al canal en Telegram

Software Engineer and IT Group: https://t.me/code_crafters_chat Github: https://github.com/CodeCrafters-ir Site: https://codecrafters.ir

Irán114 250 Tecnologías y Aplicaciones43 454

712

Suscriptores

Sin datos24 horas

Sin datos7 días

Sin datos30 días

200

Visitas de la publicación

~ 10424 horas

~ 12248 horas

28.17%

Tasa de compromiso

Sin datos

Mensajes por día

Ads index

beta

Archivo de publicaciones

712

پارتیشن‌بندی | Partitioning فکر کن یه انبار بزرگ داری پر از وسایل. بعضی هر روز استفاده میشن، بعضی یه ماه یه بار، بعضی سال به سال یه نگاه بندازیشون می‌کنی، و یه سری هم هستن که دیگه اصلا به کار نمیان. اگه همشون رو یه جا و به یه شکل نگه داری، انبارت هم شلوغ میشه، هم پیدا کردن سخته، هم نگهداری هزینه‌بر میشه. پارتیشن‌بندی دقیقا همون چوب جادویی برای انبار داده‌هایت محسوب میشه! با پارتیشن‌بندی، داده‌هات رو بر اساس استفاده و اهمیتشون طبقه‌بندی می‌کنی. به این ترتیب، اون اطلاعاتی که زیاد به کار نمیان یا دیگه قدیمی شدن رو توی بخش‌های کم‌هزینه‌تر و دورتر انبار (مثلا آرشیو) می‌ذاری، درحالیکه چیزایی که همش دم دستت هستن رو جلوی دست نگه می‌داری (مثل دیتابیس اصلی). حالا چطور این تقسیم و بخش‌بندی هزینه رو کم می‌کنه؟ یه مثال بزنیم: فرض کن انبارت پر از لباس‌های قدیمی باشه. خیلی از این لباس‌ها رو دیگه نمی‌پوشی. خب اگه همشون رو توی کمد رختخواب نگه داری، هم جای بیشتری می‌گیرن، هم هر وقت بخوای یه لباس جدید بذاری، باید همه رو جابه‌جا کنی و هم تمیز کردنشون سخته. ولی اگه اونایی که دیگه استفاده نمیشه رو ببری توی چمدون و زیر تخت بذاری، هم کمدت خلوت و مرتب‌تر می‌شه، هم دیگه لازم نیست هر دفعه همه رو جابه‌جا کنی و گردگیریشون کنی. پارتیشن‌بندی داده‌ها هم دقیقا همینطوره. اطلاعات قدیمی و کم‌کاربرد رو از دیتابیس اصلی درمیاری و به یه جای دیگه‌ای منتقل می‌کنی، مثلا یه هارددیسک دیگه‌ای یا یه سیستم آرشیو. اینجوری هم دیتابیس اصلی سریع‌تر و کوچیک‌تر می‌شه، هم هزینه‌ی نگهداری کم‌تر می‌شه. پس پارتیشن‌بندی یه راه بی‌نظیره برای اینکه هم انبار اطلاعاتی منظمی داشته باشی، هم هزینه نگهداری رو مدیریت کنی. دیگه لازم نیست نگران انبار شلوغ و هزینه‌های اضافی باشی! 👩‍💻 #postgresql @Code_Crafters

712

چرا جنگو‌ فریمورک محبوبی هست؟؟؟ بیاید یکم راجبش حرف بزنیم جنگو‌ خیلی از موارد برنامه نویسی مدرن رو براتون فراهم میکنه بدون اینکه خودتون راجبش حتی دانش کافی داشته باشید و بدونید، که میتونیم به design patterns و clean architecture اشاره کرد بارها به بچه‌ها گوشزد کردم که business logic رو فراموش نکنید و جدی بگیرید ،کار سختی نیست یک فایل با نام services.py بسازید و موارد مربوط به orm رو داخلش بنویسید (یک دایرکتوری با نام services بسازید و ماژول‌های پایتونی خودتون رو داخلش بزارید) حالا کافیه با dependency inversion principle رو بدونید و داخل کدهاتون رعایت کنید خب چه اتفاقی افتاد؟؟؟ الان شما اومدین و app رو به سه لایه تقسیم کردید لایه application ، لایه service ، لایه infrastructure , خب این چه مزیتی داره برامون بیایم ببینیم هر لایه شامل چه چیزی میشه؟؟؟

Application: urls, views
درخواست‌های مشتری در این قسمت مورد پردازش قرار میگیره که داده‌های مورد نیاز رو از لایه service میگیره و اون رو تبدیل میکنه به مقداری که قابل خوندن واسه مشتری هست که میتونه http, drf, grpc و ... باشه


Service: 
این لایه همون مبحث business logic رو ارائه میده و تمام موارد مورد نیاز رو در خودش هندل میکنه(وظیفه ذخیره و بازیابی موجودیت‌هارو برامون هندل میکنه) اینجا orm django کار میکنه لایه انتزاع از دیتابیس رو میسازه و بواسطه شی گرایی مارو از پیچیدگی کار رها میکنه

Infrastructure: migrations , models
تو این قسمت شما موجودیت‌ها و مجموعه‌ها رو در یک سیستم ذخیره ساز، ذخیره میکنید ،اینکار با استفاده از مدل‌های جنگو و queries صورت میگیره ، بخش مایگریشن‌ها هم اینجا صورت میگیره

من این همه سردرد رو واسه چی دارم تحمل میکنم خدایی؟؟؟ شما دارید ذره ذره به سمت bounded context ها میرید خب اینکه گفتیم به چه معناست اصلا؟؟ نکته: ما همیشه میگیم تسک بزرگ رو به چند تسک کوچیکتر بشکنید (بصورت منطقی البته) یک کلاس بزرگ ننویسید یک تابع طولانی نسازید ما اینهارو‌ رعایت کردیم به کجا داریم میرسیم؟؟؟ جالبه بدونید که داریم به سبک معماری DDD نزدیک میشیم بیایید ادامه بدیم خب اصل SoC میاد وسط(پروژه میتونه به بخش‌های کوچکتر و قابل مدیریت تر تقسیم بشه، اجزا میتونه میکروسرویس یا ماژولهای مستقل در یک مونولیت باشند) همین ترکیب بالا رو بزاریم داخل microservice ، پروژه خودمون رو به چند سرویس منطقی و درست تقسیم کنیم، مدلهای هر سرویس رو داخل یک دیتابیس جدا بزاریم ، FKهای مدل رو به Bigint تبدیل کنیم ارتباط‌ بین سرویس‌ها رو مدیریت و هندل کنیم (اینجا rabbitmq سلام میرسونه) الزامات سرویس‌های بیس رو انجام بدیم (این شد bounded context) چه اتفاقی داره میافته ؟؟؟

هر بخش داره بصورت مستقل توسعه داده میشه 

نگرانی حاصل از پیچیدگی داره رفع میشه

بهبود توسعه کد و پایداری داره بخوبی اتفاق میافته

پایگاه داده از شکستن داره خارج میشه

به معماری DDD خوش آمدید این معماری برای پروژه‌های بزرگ مناسبه و اگر یک پروژه قدیمی با حداقل 20 app دارید لازم نیست تعطیلش کنید فقط کافیه با DDD تبدیلش کنید

یک معماری میکروسرویس پیاده سازی کنید

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

هر سرویس در دل خودش چندتا app داره

 هر app طبق DDD به سه لایه application , services , infrastructure تقسیم میشه و دیتابیس خودش رو داره

خود جنگو براتون clean architecture رو تا سطح بالایی براتون اتخاذ میکنه 

در کدهاتون dependency inversion principle رو رعایت کنید

@code_crafters

712

محاصره در تراکنش ها یه چیزی هست که شاید خیلی‌هاتون متوجهش نشده باشید. اونم اینه که توی PostgreSQL، حتی ساده‌ترین دستورات هم توی یه تراکنش انجام می‌شن! عجیبه نه؟ شاید بگید "خب چطور می‌شه فهمید؟ ما که تراکنشی شروع نکردیم!". ولی یه خورده صبر کنید... می‌تونیم یه دستوری اجرا کنیم که برامون نشون بده الان داخل کدوم تراکنشیم. بفرما:


SELECT txid_current();

حالا چی شد؟ یه عددی بهتون نشون داد، درسته؟ ولی ما که چیزی شروع نکردیم! چون اون عددی که دیدید، شناسه‌ی تراکنشیه که همین الان توش هستید. حالا بازم همون دستور رو اجرا کنید. چی می‌بینید؟ اون عدد، یه واحد زیادتر شده! آره، این یعنی حتی همین یه دستور کوچیک، یه تراکنش جدید برا خودش باز کرده. شاید بپرسید چرا انقدر ریزه‌کاری؟ خب، اینجوری PostgreSQL، خیالش راحته که هر تغییری که انجام می‌شه، یا کاملاً انجام می‌شه، یا اصلاً انجام نمی‌شه. اگه توی یه دستور مشکلی پیش بیاد، کل تراکنش باطل می‌شه و هیچ تغییری اعمال نمی‌شه. پس یادتون باشه، توی PostgreSQL، همیشه تو یه تراکنش هستید، چه بخواهید، چه نخواهید! این یه جور مراقبت اضافه‌ست که داده‌هاتون رو سالم نگه می‌داره. #postgresql @Code_Crafters

712

تراکنش‌های پیشرفته: نقطه‌ی نجات (SAVEPOINT) یه ویژگی توپ دیگه از Postgres می‌خوام بهتون معرفی کنم که کار با تراکنش‌ها رو توی شرایط پیچیده خیلی راحت‌تر می‌کنه. اسمش "نقطه‌ی نجات" یا SAVEPOINT هست. تصور کنید یه تراکنش دارید و چند تا دستور داخلش انجام می‌دید. شاید بخواهید یه جایی وسط کار، یه نقطه‌ی امن داشته باشید که اگه هر اتفاقی افتاد، بتونید به اونجا برگردید و همه چی رو از اول انجام بدید. SAVEPOINT دقیقا همینه! بذار یه مثال بزنم. فرض کنید می‌خوایم یه کارمند جدید به اسم Bob Young اضافه کنیم، بهش چندتا وابسته اضافه کنیم و بعد تراکنش رو تموم کنیم. ولی ممکنه یه جا تو کار اشتباهی پیش بیاد. برای همین از SAVEPOINT استفاده می‌کنیم:

BEGIN;

INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id) VALUES ('Bob', 'Young', current_date, 1, 'Jr Director of the Highwire', 2, 2);

SAVEPOINT saved_employee;  // این نقطه‌ی نجاته!

INSERT INTO dependents (first_name, last_name, employee_id) VALUES ('oldest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));

INSERT INTO dependents (first_name, last_name, employee_id) VALUES (null, 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));

ROLLBACK TO SAVEPOINT saved_employee;  // اگه یه مشکلی پیش بیاد، به نقطه‌ی نجات برمی‌گردیم!

COMMIT;

حالا اگه اسم Bob Young رو توی کارمندها Search کنیم، پیداش می‌کنیم، ولی وابسته‌هایش رو نمی‌بینیم. چرا؟ چون وقتی توی اضافه کردن وابسته‌ها یه خطایی پیش اومده، تراکنش رو به نقطه‌ی نجات برگردوندیم و فقط اضافه‌کردن Bob Young انجام شده. می‌دونم این مثال یه کم مصنوعیه، ولی SAVEPOINT توی شرایط پیچیده‌تری که معمولاً برنامه‌نویس هم باهاش درگیره، خیلی کارآمد میشه. فعلاً شاید لازم نباشه ازش استفاده کنی، ولی خوبه بدونی همچین ویژگی‌ای وجود داره! #postgresql @Code_Crafters

712

تغییرات ساختار در تراکنش ها شاید تعجب کنید، اما PostgreSQL اونقدر باحال هست که هیچ تغییری توی ساختار پایگاه داده رو ثبت نمی‌کنه تا زمانی که کل تراکنش با موفقیت انجام بشه! این ویژگی توی دنیای پایگاه‌های داده خیلی خاصه و خیالمون رو راحت می‌کنه. بذارید با یه مثال براتون توضیح بدم. فرض کنید می‌خوایم یه ستون جدید به اسم "middle_name" به جدول "employees" اضافه کنیم. برای این کار، از دستورات زیر استفاده می‌کنیم:

BEGIN;
ALTER TABLE employees ADD COLUMN middle_name VARCHAR(50) DEFAULT NULL;
COMMIT;

دستور "BEGIN" شروع تراکنش رو مشخص می‌کنه و دستور "COMMIT" هم پایان تراکنش رو نشون می‌ده. هر تغییری که بین این دو دستور انجام بشه، تا زمانی که دستور "COMMIT" اجرا نشه، ثبت نمی‌شه. حالا اگه از دستور \d employees استفاده کنیم، می‌بینیم که ستون "middle_name" به جدول اضافه شده. اما اگه یه تغییر پیچیده‌تر بخوایم انجام بدیم و یه اشتباه کوچولو توش داشته باشیم، چی می‌شه؟ مثلاً فرض کنید می‌خوایم چند تا ستون جدید برای آدرس به جدول اضافه کنیم، اما یادمون بره که برای ستون "postal_code" یه مقدار پیش‌فرض تعیین کنیم. دستورات زیر رو ببینید:

BEGIN;
ALTER TABLE employees ADD COLUMN address_line_1 VARCHAR(50) DEFAULT NULL;
ALTER TABLE employees ADD COLUMN address_line_2 VARCHAR(50) DEFAULT NULL;
ALTER TABLE employees ADD COLUMN city VARCHAR(50) DEFAULT NULL;
ALTER TABLE employees ADD COLUMN province VARCHAR(50) DEFAULT NULL;
ALTER TABLE employees ADD COLUMN postal_code VARCHAR(50) NOT NULL;
COMMIT;

به خاطر اینکه کل این تغییرات داخل یه تراکنش قرار گرفتن، و چون برای ستون "postal_code" مقدار پیش‌فرض تعیین نکردیم، هیچ کدوم از تغییرات ثبت نمی‌شن! یعنی اگه دوباره از دستور \d employees استفاده کنیم، می‌بینیم که ستون‌های آدرس اضافه نشدن. به این ویژگی فوق‌العاده می‌گن "Transactional DDL". توی پایگاه‌های داده دیگه که این ویژگی رو ندارن، ممکنه تغییرات نصفه و نیمه انجام بشن و همه چیز بهم بریزه. اما توی PostgreSQL، یا همه تغییرات با موفقیت انجام می‌شن، یا هیچ تغییری ثبت نمی‌شه. #postgresql @Code_Crafters

712

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

BEGIN; 
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id) VALUES ('Chris', 'Winslett', current_date, 1, 'Jr Director of the Highwire', 2, 2);   
INSERT INTO dependents (first_name, last_name, employee_id)  VALUES ('oldest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Chris' AND last_name = 'Winslett'));   
INSERT INTO dependents (first_name, last_name, employee_id) VALUES ('youngest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Chris' AND last_name = 'Winslett')); 
COMMIT;

اگه دوباره همون کد بالا رو اجرا کنید، بازم با خطا مواجه می‌شید. دلیلش اینه که دوتا مقدار برای employee_id برمی‌گرده. همچنین، کارمند تکراری هم ایجاد نمی‌شه. وای! چقدر تراکنش‌ها عالین! حالا بیایید یه کاری کنیم که ببینیم چطوری تراکنش‌ها با خطا مواجه می‌شن. اول، سعی می‌کنیم مقدار null رو برای فیلد first_name در دستور دوم قرار بدیم. این فیلد توی جدول اجباریه، پس تراکنش با شکست مواجه می‌شه. بعد، حقوق (salary) رو حذف می‌کنیم. این کار باعث لغو تراکنش قبل از تاییدش می‌شه.

BEGIN;   
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id) VALUES ('Bob', 'Young', current_date, 1, 'Jr Director of the Highwire', 2, 2);   
INSERT INTO dependents (first_name, last_name, employee_id) VALUES ('oldest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));   
INSERT INTO dependents (first_name, last_name, employee_id) VALUES (null, 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young')); 
COMMIT;

حواست باشه! اجرای کدی که دیدی، با خطا مواجه شده و به عقب برگشته. یعنی تغییراتی که قرار بود اعمال بشه، ذخیره نشده. نگران نباش، اینجوری اطلاعاتت سالم می‌مونه. برای اطمینان بیشتر، می‌تونی یه سرچ بزنی و ببینی که اسم "Bob Young" توی لیست کارمندا نیست. خیالت راحت!

SELECT *  FROM employees  WHERE  first_name = 'Bob' AND last_name = 'Young';

دلیل این امر این است که تراکنش به طور کامل انجام نشد. این یک حالت "همه یا هیچ" است. #postgresql @Code_Crafters

712

رازهای مخفی تراکنش‌های پایگاه داده: هرچی توی تراکنش هست، همونجا میمونه! (Transaction Scope) تصور کن یه صندوق داری داری که توش کلی کارای عجیب غریب میشه، ولی هیچکس اجازه نداره سرک بکشه تا وقتی کار تموم نشده! همینه داستان تراکنش‌های پایگاه داده. فرض کن داری تو دوتا کامپیوتر جدا جدا با یه پایگاه داده کار می‌کنی. کامپیوتر اول یه سری دستورات میده، مثلاً یه اطلاعاتی رو عوض می‌کنه یا یه چیزی اضافه می‌کنه، ولی هنوز کارش تموم نشده. حالا کامپیوتر دوم بخواد همون اطلاعات رو ببینه، چی میشه؟ خب، تا وقتی که کارِ اون یکی کامپیوتر تموم نشده و همه چی تایید نشده، کامپیوتر دوم چیزی نمیبینه! مثل همون صندوقه، اطلاعات تغییرات مخفیه تا کار تموم نشده، بعدش همه می‌بینن چی به چیه. اینجوری مطمئن می‌شیم که همه اطلاعات با هم هماهنگه و هیچ قاطی‌بازی‌ای نمیشه. پس یادت باشه، تراکنش‌ها مثل یه سری کارای مخفی تو صندوق می‌مونن تا همه چی جمع و جور بشه. هیچکس زودتر از موعد حق نداره سرک بکشه! #postgresql @Code_Crafters

712

تراکنش های ابتدایی ساده‌ترین تراکنش در زیر آمده است. با استفاده از BEGIN تراکنش را شروع کرده و با COMMIT آن را پایان می‌دهد.

sql 

BEGIN;
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id) VALUES ('Elizabeth', 'Christensen', current_date, 1, 'Master of the Highwire', 2, 2) RETURNING employee_id;
COMMIT;

مثل آب خوردن کار کرد، درسته؟ شبیه اینه که یه دستور معمولی رو اجرا کنیم ( داریم از دستور RETURNING استفاده می‌کنیم تا بعداً چیزی رو ثابت کنیم). برای اینکه مطمئن بشید داده‌ها ثبت شدن، حالا این دستور رو بزنید:

SELECT    * FROM employees  WHERE    first_name = 'Elizabeth' AND    last_name = 'Christensen';

اما اگر تصمیم بگیرید به جای COMMIT، تراکنش را ROLLBACK کنید، نتیجه‌ای متفاوت خواهید داشت:

BEGIN;

INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id) VALUES ('Chris', 'Winslett', current_date, 1, 'Jr Director of the Highwire', 2, 2) RETURNING employee_id;

ROLLBACK;

وقتی از دستور ROLLBACK استفاده می‌کنی، مثل این میمونه که داری به پایگاه داده میگی: «بیخیال این تراکنش شو، انگار نه انگار اتفاقی افتاده.» با این کار، هر تغییری که توی تراکنش انجام شده بود، پاک میشه و توی تاریخچه پایگاه داده ذخیره نمیشه. اما یه نکته جالب اینجاست: با اینکه تراکنش ثبت نمیشه، اما پایگاه داده باز هم یه شناسه برای اون تراکنش در نظر می‌گیره. ولی اگه بعدا بخوای اون رکورد رو با دستور select پیدا کنی، هیچی پیدا نمیشه، چون از اول ثبت نشده بوده!!

SELECT * FROM employees WHERE first_name = 'Chris' AND last_name = 'Winslett';

می‌دونی چرا وقتی یک تراکنش رو شروع می‌کنی، حتی قبل از اینکه اون رو نهایی کنی، یک مقدار شناسه (ID) بهت برمی‌گردونه؟ ببین، تراکنش‌ها گروهی از عملیات‌های پایگاه داده هستن که با هم انجام می‌شن. گاهی اوقات، لازمه که یک مقدار شناسه یکتا برای هر رکوردی که وارد پایگاه داده می‌کنیم، داشته باشیم. برای این کار، از دنباله‌ها (sequences) استفاده می‌کنیم. دنباله‌ها، مقدار شناسه بعدی رو به صورت خودکار تولید می‌کنن. حالا، فرض کن که دو تراکنش همزمان دارن داده وارد پایگاه داده می‌کنن. اگه هر دو تراکنش از دنباله‌ای استفاده کنن که هنوز نهایی نشده، ممکنه هر دو تراکنش مقدار شناسه یکسانی رو دریافت کنن. این باعث می‌شه که دو رکورد با یک شناسه یکسان در پایگاه داده وجود داشته باشن. این کار درست نیست و می‌تونه باعث مشکلاتی بشه. برای جلوگیری از این مشکل، دنباله‌ها حتی قبل از اینکه تراکنش نهایی بشه، مقدار شناسه بعدی رو تولید می‌کنن. این کار باعث می‌شه که هر دو تراکنش مقدار شناسه متفاوتی رو دریافت کنن. حالا، اگه تراکنش رو نهایی نکنی، مقدار شناسه‌ای که بهت برمی‌گردونه، فقط یک مقدار موقتی هست. این مقدار تا زمانی که تراکنش نهایی بشه، در پایگاه داده ذخیره نمی‌شه. اگه تراکنش رو با دستور ROLLBACK لغو کنی، مقدار شناسه‌ای که بهت برمی‌گردونده، از بین می‌ره. برای اینکه مطمئن بشی که مقدار شناسه‌ای که دریافت می‌کنی، در پایگاه داده ذخیره شده، باید تراکنش رو با دستور COMMIT نهایی کنی. اگه در حین انجام تراکنش، خطا رخ بده، نمی‌تونی اون رو نهایی کنی. در این صورت، مقدار شناسه‌ای که دریافت می‌کنی، در پایگاه داده ذخیره نمی‌شه.

BEGIN;
INSERT INTO employees (first_name, last_name) VALUES ('Tom', 'Jones') RETURNING employee_id;
COMMIT;

بعد از اجرای دستور بالا، یک دستور ROLLBACK نشان داده خواهد شد. بنابراین، دستور COMMIT ناموفق بوده است زیرا آخرین وضعیت تراکنش یک خطا است. #postgresql @Code_Crafters

712

تراکنش در دنیا پایگاه داده ها: قهرمان‌های گمنامِ پشت صحنه 💪 در دنیای پایگاه داده، تراکنش (Transaction) مثل یه گروه سربازه که یا با هم تا تهِ خط می‌رن، یا همه با هم برمی‌گردن. وقتی حرف از تراکنش ها می‌شه، خیلی‌ها یاد تراکنش حساب‌های بانکی میفتن و با خودشون می‌گن: «وا، من که به این پیچیدگی‌ها نیاز ندارم!» اما حقیقت اینه که تراکنش ها فقط مال پایگاه‌های داده‌ی بانک‌ها نیستن. خیلی وقت‌ها مردم گیر یه سری مثال‌های بانکی می‌افتن و فراموش می‌کنن که تو دنیای واقعی، تراکنش ها چقدر کاربرد دارن. با استفاده از تراکنشها برنامه‌نویس‌ها نه تنها وقتِ خودشون رو ذخیره می‌کنن، بلکه کد مورد نیازشون برای برنامه‌هایی که به پایگاه داده وابسته هستن رو هم کم می‌کنن. اگه پایگاه داده خودش وضعیت تراکنش رو مدیریت نمی‌کرد، باید خود برنامه‌نویس این کار رو انجام می‌داد. به نظر ساده میاد، ولی وقتی با داده‌های مرتبط به هم سروکار داشته باشیم، خیلی زود پیچیده می‌شه. مثلاً به مراحل ثبت‌نام ساده‌ی یه کاربر فکر کنین. این مراحل باید یه رکورد کاربر و یه رکورد حساب بسازن و بعد اون‌ها رو به هم وصل کنن. بدون تراکنش باید تک تک مراحل رو تو برنامه بنویسیم: کاربر رو بساز اگه موفق نبود، خارج شو و پیام خطا بفرست حساب رو بساز اگه موفق نبود، کاربر رو حذف کن، خارج شو و پیام خطا بفرست کاربر رو به حساب وصل کن اگه موفق نبود، کاربر، حساب رو حذف کن، خارج شو و پیام خطا بفرست اما با تراکنش، می‌تونیم راحت‌تر و تمیزتر عمل کنیم: تراکنش رو شروع کن حساب رو بساز کاربر رو بساز کاربر رو به حساب وصل کن تراکنش موفقیت‌آمیز بود؟ اگه آره، پیام موفقیت رو برگردون اگه نه، پیام خطا رو برگردون حالا دیگه نگران این نیستیم که بخاطر یه دستوری که موفق نشده، بقیه رو پاک کنیم. یا همه با هم درست انجام می‌شن، یا همه با هم شکست می‌خورن. به همین سادگی! خب، حالا می‌بینیم که تراکنش ها نه تنها پیچیده نیستن، بلکه تو خیلی از کارها می‌تونن دست چپ و راست برنامه‌نویس‌ها باشن. دیگه این قهرمان‌های گمنام دنیای پایگاه داده رو دست‌کم نگیرین! #postgresql @Code_Crafters

712

اگه به این سوال ها علاقه دارید (علاقه موج میزنه ☹️) میتوانید از سایت هکر رنگ استفاده کنید سوال ها از ساده تا پیشرفته طبقه بندی و جز SQL چند تا زبان برنامه نویسی دیگه هم پشتیبانی میکنه اگر جواب سوالی نتوانستید پاسخ بدهید میتوانید از بخش بحث(Discussions) جواب را پیدا کنید اگر توانستید حل کنید هم باز سری به این بخش بزنید و جواب های دیگران ببینید دید خوبی از SQL به دست می آورید . https://www.hackerrank.com/

712

یکی از جواب های ممکن :

WITH RECURSIVE CTE AS (
    SELECT 20 N
    UNION ALL
    SELECT N - 1 FROM CTE WHERE N > 0
)
SELECT REPEAT('* ', N) FROM CTE

این خدایی سخت بود

712

SELECT Continent, FLOOR(AVG(CITY.Population)) AS AveragePopulation
FROM CITY
JOIN COUNTRY ON CITY.CountryCode = COUNTRY.Code
GROUP BY Continent;

712

```sql

SELECT Continent, FLOOR(AVG(CITY.Population)) AS AveragePopulation
FROM CITY
JOIN COUNTRY ON CITY.CountryCode = COUNTRY.Code
GROUP BY Continent;

```

712

جواب :
SELECT Name FROM 
WHERE Population > 120000 AND Country == "IR";

712

با توجه به استقبال بسیار زیاد و خیره کننده دوستان (تا این لحظه فقط یک نفر جواب داد😕 ) جواب سوال های SQL رو قرار میدهم.

712

یجوری اعدام کردن داخل کشور شدت گرفته اونم قبل از انتخابات حس میکنم تا اسفندماه بالای هر صندوقی یک طناب دار میزارن و هرکسی رای بده رو ،دار میزنن همونجا، بجای مستقر کردن ماشین انتظامی هم ،نعش کش تو حوزه‌ها بزارن فقط برام سوال شده قوه قضاییه داره علیه قوه مقننه اقدام میکنه تا نابود و بی ارزشش کنه؟؟؟ #موقت

712

نکته ای باید در نظر بگیرد این است که به صورت پیشفرض پایگاه داده MySQL در نظر گرفته شده است . و اینکه طبقه بندی ها بر اساس دانش لازم از SQL است . جواب ها تا فردا یا اگر تعداد زیادی سوال را جواب دادند زودتر قرار خواهد گرفت . راهنمایی ها سعی بر روشن کردن مسیر بوده و جواب نهایی نیستند!!! #SQL @Code_Crafters

712

سطح پیشرفته شکل زیر :

sql 
*****
****
***
**
*

را در نظر بگیرید که تابع P(5)را نشان میدهد شما کوئری را بنویسید که این شکل را تا ۲۰ ستاره یا P(20 )را پرینت کند راهنمایی :می‌توان از WITH و UNION ALL برای ایجاد یک جدول مجازی استفاده کرد که حاوی تمام حالت‌های ممکن از تعداد ستاره‌ها است. سپس، می‌توان از تابع REPEAT در MySQL برای تکرار این چرخه تا زمانی که تعداد ستاره‌ها به ۲۰ برسد، استفاده کرد. #SQL @Code_Crafters

712

پرسش: با توجه به جداول CITY و COUNTRY، نام همه قاره‌ها (COUNTRY.Continent) و میانگین جمعیت شهر مربوطه (CITY.Population) را که به نزدیک‌ترین عدد صحیح گرد شده است، جستجو کنید. نکته :از CITY.CountryCode و COUNTRY.Code برای JOIN زدن استفاده کنید. سطح : متوسط راهنمایی : استفاده از تابع های درونی AVG برای میانگین گیری و FLOOR برای گرفتن نزدیک ترین عدد صحیح و همچنین JOIN زدن بین دو جدول و در نهایت استفاده از GROUP . #SQL @Code_Crafters