برنامه‌ی SQLite manager

یک تک فایل PHP و یک دنیا کار عجیب از تولید دیتابیس تا مدیریت ساختار و دیتا!
درضمن به کمک KS-WEB به راحتی میشه سِرور PHP با همون کیفیت XAMPP روی اندروید راه اندازی کرد و همزمان که هوش مصنوعی براتون از این کدهای زیبا می نویسه همونجا داخل موبایل حتا تست کرد!

برنامه‌ی System maker

       یک جور PHP maker ولی این بار تحت وب و بدون قفل و رایگان!
دیتابیس را از شما گرفته و یک سیستم کامل با بخش های امنیتی برای ورود و نگهداری و گزارش گیری اطلاعات می سازه!
وجه تمایز دیگه اش هم با هر برنامه‌ی پیچیده ای از این دست اینه که کل دار و ندارش همین یک فایل هست!
این برنامه نه تنها خودش ۲ زبانه است. بلکه برنامه هایی هم که تولید می کنه رو می تونی انتخاب کنی که رابط کاربریش فارسی تولید بشه یا انگلیسی!

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


@SohrabContents

جنگو کنده، پس نباید استفاده کنیم؟ 🙂‍↔️

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

چرا میگن جنگو کنده؟
خب راستشو بخواین، جنگو واقعا کنده (نسبت به فریم‌ورک‌های async بیس مثل FastAPI و زبان‌های کامپایلری مثل Go که توی I/O bound حرف اولو میزنن). ولی چرا؟

جنگو سینکروسه 🥸
جنگو از اساس برای وب‌اپلیکیشن‌های سنتی طراحی شده(طبیعیم هست چون ۲۰ سال پیش ساخته شد اون موقع مفهومی به اسم async به این صورت نبود).
ولی فریم‌ورک‌هایی مثل FastAPI می‌تونن همزمان چند درخواست رو مدیریت کنن (به لطف async).

‏Overhead بالای ORM 🏋️‍♂️
‏ORM جنگو سنگینه. هر کوئری که میزنی، کلی پردازش اضافه انجام میده تا کارتو راحت کنه، ولی همین باعث میشه کندتر از ORMهای سبک‌تر باشه.

‏Middleware و Request Cycle پیچیده‌تره 🌀

جنگو یه سری پردازش‌های اضافه برای هر درخواست انجام میده (مانند middleware ها، سیگنال‌ها، template rendering و ...)، که باعث میشه به طور طبیعی کمی کندتر باشه.

پس چرا بازم از جنگو استفاده کنیم؟
حالا که جنگو کنده، یعنی نباید سمتش بریم؟ نه بابا بذار تجربه خودمو بگم.

1⃣ سرعت، همیشه مهم‌ترین فاکتور نیست
اکثر پروژه‌ها، گلوگاه سرعت، فریم‌ورک نیست، بلکه دیتابیس، شبکه، و لاجیک‌های بیزینسی هستن. یه اپلیکیشن CRUD ساده که روزی ۱۰۰۰ تا درخواست داره، با FastAPI یا جنگو، تفاوت محسوسی نداره.

2⃣ توسعه سریع‌تر = زمان و پول بیشتر
جنگو کلی چیز آماده داره. سیستم مدیریت کاربر، فرم‌ها، ORM، ادمین پنل، و کلی ماژول دیگه. این یعنی تو به جای ساختن همه‌چی از صفر، فقط تمرکزت روی بیزینس لاجیکه. توسعه سریع‌تر = هزینه کمتر.

3⃣ امنیت، یکپارچگی، و قابلیت اطمینان
جنگو به طور پیش‌فرض مقاوم در برابر حملات XSS، CSRF، SQL Injection و غیره‌ست. ولی FastAPI؟ باید خودت امنیت رو درست کنی و Middleware بنویسی، که اگه اشتباه کنی، فاجعه میشه

کی بریم سمت FastAPI یا Go یا هرچیز سریع؟

1⃣ وقتی واقعا به Async نیاز داری
اگه داری یه چت‌اپ، وب‌ساکت، یا یه سیستم پردازش سنگین با درخواست‌های همزمان بالا می‌نویسی، FastAPI و Go گزینه‌های بهتری هستن.

2⃣ وقتی هر میلی‌ثانیه مهمه
توی سرویس‌های real-time مثل سیستم‌های تریدینگ، گیمینگ، یا پردازش داده سنگین، Go و Rust گزینه‌های بهتری هستن، چون کامپایل میشن و خیلی سریع‌تر از پایتون اجرا میشن.

پس چی کار کنیم؟

اگه سرعت برات مهمه: Go بزن Java بزن یا ...

اگه یه API سبک و سریع لازم داری: FastAPI بزن

اگه می‌خوای سریع یه اپلیکیشن کامل و امن بالا بیاری: Django بهترین گزینه‌ست

سرعت، همه چیز نیست، بلکه بستگی داره که چه چیزی برات مهم‌تره و نیاز داری بهش

خوشحال میشم نظرتون رو بشنوم
تو کامنتای همین پست بگید 👇

#️⃣ #programming #django #backend

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

سلام به همه دوستان
نتیجه قرعه کشی اعلام شد و به دوستانی که برنده شدند پیامک ارسال شد

۱۰ میلیون تومان مبلغ قرعه کشی به حساب خانه ای بی واریز شد

فیش واریزی قرعه کشی های قبلی
https://news.1rj.ru/str/c/1525472919/2990

https://news.1rj.ru/str/c/1525472919/2177

https://news.1rj.ru/str/c/1525472919/2504

@gocasts

ا DBMS ها یه کار دیگه میکنن 😅
چون خوندن از ایندکس و بعد خوندن دیتا از رو دیسک زمان بره. دیتابیس ها تصمیم میگیرن که اصن از ایندکس بخونن یا نه مثلا توی پست گرس planner این کار رو میکنه.
سه تا حالت ممکنه پیش بیاد:

1⃣ Scan index
کوئری ما دامنه چیزهای که میخواد بگیره نسبت به جدول کمه. پس میرم ایندکس رو میخونم

2⃣ Bitmap index scan
این برای موقعی که بخش بزرگی از جدول رو میخوایم برگردونیم، توی این حالت کل درخت ایندکس خونده میشه و pageهای که اطلاعات ما توشه علامت گذاری میشن تا در مرحله بعد دیتا ها خونده شن

3⃣ Full table scan
توی این حالت دیتابیس به ما میگه: داداش این چیزی که میخوای تقریبا کل جدوله من اگه از ایندکس استفاده نکنم سریعترم😂

اها این توییتر snowflake هم داشته باشیم یه کار دیگه هم باهاش میتونیم بکنیم:

توی کوئری های pagination داره ما از offset استفاده میکنیم این یعنی اگه جدول ما 100000010 تا رکورد داشته باشه و ما فقط ۱۰ تاشو بخوایم، همه اش از روی دیسک گرفته میشه ۱۰ تای لازم رو میده بهمون و بقیه رو دراپ میکنه، چقدر دهشتناک...

حالا ما میتونیم به جای افست بیایم بر اساس id خود ساخته خودمون کار کنیم

Select * from people order by sid desc where sid > 1029383737 limit 10;

این io اش خیلی کمتره. یعنی خیلی خیلی کمتره

توی btree معمولی اگه بخوایم یه کوئری رنج بزنیم مثلا

Select * from people where id > 10

درخت btree ما بارها و بارها Traverse میشه. یادمون باشه که ایندکس خودش یه io هستش و خوندن دیتاها یه io دیگه.

اینکار اصلا بهینه نیست، بخاطر همین dbms ها رفتن روی الگوریتم b+tree

اB+tree دقیقا مثله btree هستش ولی اطلاعات توی leaf ها ذخیره میشن فقط این باعث دوتا چیز میشه:

۱. هر نودی که میخونیم چون دیتای نداره(به غیر از لیف ها) لحاظ به حجمی سبک تره، io سریعتری خواهیم داشت.

۲. چون اطلاعات در لیف ها هستن میتونیم لیف ها رو با لینکدلیست بهم وصل کنیم تا کوئری های range خیلی خیلی سریعتر اجرا شن