1. cache
1.1. کی از دیستریبیوتد کش استفاده میکنیم
1.1.1. زمانی که سیستم خیلی بزرگه
1.1.2. زمانی که میخوایم سیستم رو به صورت هوریزانتالی اسکیل کنیم چون فقط کافیه سرور جدید اضافه کنیم
1.1.3. زمانی که فالت تالرنس داشته باشیم یعنی اگه یکی از سرورامون از کار افتاد بقیه به کارشون ادامه بدن
1.1.4. زمانی که میخوایم یک سرور باتلنک نباشه
1.1.5. زمانی که بخواهیم سیستممون اسکیلبل باشه ولی باید حواسمون به هزینه و نتورک لیتنسی باشد
1.2. چه زمانی از co located کش سرور استفاده میکنیم
1.2.1. زمانی که میخوایم تو هزینه هامون صرفه‌جویی کنیم
1.2.2. زمانی که سیستم ما کوچیکه و و میشه با انجام دادن این کار low latency داشته باشیم
1.3. مکانیزم ساختن کلید در کشینگ توزیع شده چیست؟
1.3.1. با یک کلاینت لایبرری کلیدها ساخته میشن به طوری که مشخص میشه کش در کدام سرور قرار گرفته است
1.4. ممکش فیچر خاصی نداره و صرفاً برای کش کردن اطلاعات کاربرد داره و خب به تبعش سبکه
1.5. برای اینکه از ارسال ریکوست های پرشمار به دیتابیس در هنگام cold state جلوی گیری کنیم چه راه هایی داریم؟
1.5.1. mutex
1.5.2. سمافور
1.5.2.1. مکانیزمی که تضمین میکنه در لحظه تعداد معینی ریکوست از یک منبع استفاده میشه (با استفاده از chan)
1.6. استراتژی حذف
1.6.1. LFU (Least frequently used)
1.6.1.1. gboard
1.6.2. RFU (Recently frequently used)
1.6.3. LIFO
2. DSA
2.1. تو مسأله ی مرج دو ارایه ی سرت شده که یکیشون از انتها فضای خالی داشت، با روش ۲ pointer از انتها مسأله شد.
2.2. self balanced trees
2.2.1. avl
2.2.2. btree
2.3. graph
2.3.1. matrix or list
2.3.1.1. for dense graph use matrix otherwise use list
3. انواع دیپلویمنت
3.1. canary deployment
3.1.1. تعداد کمی از کاربران به صورت تدریجی.
3.2. green blue deployment
3.2.1. تمام کاربران به یکباره پس از سوئیچ.
4. چک سام چیه؟
4.1. یه جاهایی نیاز داری فقط مطمئن باشی که داده های دریافتی بدون هیچ کم و کاستی دقیقا همون هایی هستن که باید باشن و فقط همین مثلا میخوایم فایل دانلود کنیم - دیتا بین سرویس های مختلف بفرستیم - بک آپ بگیریم ولی اگه بخوای امنیت رو رعایت کنی که مثلا کسی نیومده باشه داده رو دستکاری کرده باشه باید از رمزنگاری استفاده کنی (public key private key) روش هایی که داره مثل بیت پرایتی که میگه مثلا تعداد بیت ها باید فرد باشه یکی اضافه میکنیم و ... در کل این روش زیاد کارامد نیست و برای تغییرات چند بیتی جالب نیست همون md5 کنیم و ... بهتره
5. CDN
5.1. به‌عنوان مثال، وقتی کاربری صفحه‌ای را در اپلیکیشن شما بارگذاری می‌کند، CDN ممکن است فایل‌های تصویری، CSS، یا ویدیوهای آن صفحه را از نزدیک‌ترین سرور به کاربر ارسال کند. اما اطلاعات داینامیک که به‌طور خاص برای هر کاربر یا درخواست تولید می‌شود، مثل داده‌های کاربر از پایگاه داده، معمولاً توسط سرورهای اصلی شما مدیریت می‌شود و در CDN ذخیره نمی‌شود.
5.2. بهبود زمان بارگذاری وب‌سایت
5.3. کاهش هزینه‌های پهنای باند
5.4. افزایش دسترس‌پذیری و پایداری محتوا
6. restful arc
6.1. Do not use verbs in URIs
6.1.1. GET: /books/createNewBook/
6.2. Use plural nouns for resources
6.3. Pay special attention to HTTP status codes
6.4. The HTTP 204 status code, known as “No Content,” means that the server successfully processed the client's request but does not need to return any content
6.5. Do not nest resources
6.5.1. /books?author=Cagan
6.6. Handle trailing slashes gracefully
7. message brokers
7.1. RabbitMQ
7.1.1. انواع exchange
7.1.1.1. direct
7.1.1.1.1. با روتینگ کی مشخص میشه تو کدوم صف بره
7.1.1.2. topic
7.1.1.2.1. با وایلدکارد تاپیک مشخص میشه تو کدوم صف ها بره
7.1.1.2.2. با وایلدکارد تاپیک مشخص میشه تو کدوم صف ها بره
7.1.1.3. fanout
7.1.1.3.1. هیچ فیلتری وجود نداره و به همه ی صف ها میره
7.1.1.4. headers
7.1.1.4.1. نمیدونم
7.1.2. انواع پترن
7.1.2.1. pub/sub
7.1.2.2. RPC (request/reply)
7.1.2.3. Work Queues
7.1.2.4. Broadcast
7.1.2.5. P2P (point to point)
8. sorting
8.1. Patience Sorting
8.1.1. دونه دونه از چپ شروع میکنی و کارت ها رو به صورت ستونی میچینی
8.1.2. شرط چینش اینکه که هر کارت باید از کارت بالاییش کوچیکتر باشه
8.1.3. آخرین کارت هر ستون رو نگاه میکنیم و بررسی میکنیم که آیا کارتی که قراره جایگذاری شه از اون کارت کوچیکتره
8.1.4. اگه ستونی با چنین شرایطی وجود نداشت یه ستون جدید درست میکنی
8.1.5. وقتی ستونی جدید ایجاد میشه آخرین کارت ستون آخر مارک میشه
8.1.6. تعداد ستونی که تشکیل شده میشه طول LIS
8.1.7. در نهایت مارکر ها رو از آخر به اول میخونیم و میشه LIS
9. Why Pass db to Handlers?
9.1. Separation of Concerns: Keep your handlers focused on their task (handling requests), not creating/managing DB connections.
9.2. Reusability: If the handlers take db as a parameter, they can be reused across multiple places or services.
9.3. Testing: You can pass mock db connections for unit tests, making your code easier to test.
9.4. Connection Pooling: Avoid creating a new connection for every request; pass a shared instance.
10. rate limiting
10.1. strategies
10.1.1. Token Bucket
10.1.1.1. amazon
10.1.2. Leaky Bucket
10.1.3. Sliding Window
10.1.4. fixed window
10.2. سطح‌بندی محدودیت‌ها
10.2.1. کاربر مهم و کاربر عادی نباید محدودیت یکسان داشته باشن.
10.2.2. یه کاربر لاگین‌شده می‌تونه درخواست‌های بیشتری نسبت به یه کاربر مهمان بفرسته.
10.3. Rate Limiting روی API Gateway
10.4. ریت لیمیتینگ به‌تنهایی کافی نیست، اونو با CAPTCHA، تحلیل رفتار کاربر و سیستم‌های امنیتی ترکیب کن.
11. bloom filtering
11.1. مثال متصدی و کتابخونه که هر دفعه مجبوره بره بگرده ببینه هست یا نیست
11.2. اگه بخوایم ترو نگتیومون کم شه میتونیم از هش فانکشن های بیشتر استفاده کنیم و فضا رو هم بیشتر کنیم
11.3. عملیات دیلیت امکان پذیر نیست و باید از روش هایی مثل Cuckoo Filter و Counting Bloom Filter (CBF) (More memory usage) و Stable Bloom Filter (SBF) (داده های قدیمی حذف میشن به صورت دوره ای) استفاده کنیم
12. microservices
12.1. ارتباط بین سرویس ها
12.1.1. راه حل
12.1.1.1. grpc
12.1.1.2. message brokers
12.2. کشف سرویس
12.2.1. باید بخونم
12.3. تست و مانیتورینگ سخت
12.4. مدیریت دیتا
12.4.1. ترجیحات
12.4.1.1. هر سرویس دیتابیس مستقل خودش رو داشته باش
12.4.2. سازگاری نهایی (Eventual Consistency)
12.4.3. Event Store (ذخیره‌سازی رویدادها)
12.4.3.1. اگر یک سرویس یک رویداد رو از دست بده یا بخواد داده‌هاش رو دوباره همگام کنه، می‌تونه از Event Store همه رویدادهای قدیمی رو دریافت کنه و وضعیت فعلی خودش رو بازسازی کنه.
12.4.4. Reconciliation
12.4.4.1. اگر ناسازگاری داده‌ها شناسایی شد، از بازپرس (Reconciliation) استفاده کنید تا داده‌ها رو با هم مقایسه و اختلافات رو حل کنید.
12.5. چالش ها
12.5.1. بخوایم یه دیتایی رو از چند تا دیتابیس مختلف بگیریم
12.5.1.1. اگر انعطاف‌پذیری بالا می‌خواهید، GraphQL Gateway مناسبه.
12.5.1.1.1. پیچیدگی در پیاده‌سازی Gateway.
12.5.1.1.2. نیاز به طراحی مناسب برای جلوگیری از درخواست‌های سنگین.
12.5.1.2. اگر سیستم شما تعداد زیادی کوئری بین دیتابیس‌ها داره، Data Replication بهترین گزینه هست
12.5.1.2.1. به‌روزرسانی داده‌ها باید هماهنگ باشه.
12.5.1.2.2. هزینه و پیچیدگی برای نگهداری داده‌های تکراری.
12.5.1.3. اگر به دنبال استقلال کامل سرویس‌ها هستید، Orchestration یا Choreography منطقی‌تره.
12.5.1.3.1. افزایش latency (به دلیل فراخوانی چند سرویس).
12.5.1.3.2. نیاز به کد اضافی برای مدیریت ترکیب داده‌ها.
12.5.1.3.3. تو Choreography از request-reply پترن استفاده میکنیم برای اینکه داده ها رو از consumer های مختلف جمع کنیم و در نهایت ترکیبشون میکنیم و برمیگردونیم
12.6. patterns
12.6.1. SAGA
12.6.1.1. برای مدیریت تراکنش‌های توزیع‌شده
12.6.1.2. وقتی یه تراکنش شامل چند سرویس مختلف باشه و بخوای اطمینان پیدا کنی که همه مراحل به درستی انجام میشن یا اگه یکی شکست خورد، کل عملیات به حالت قبلی برگرده، از Saga استفاده میکنی.
12.6.1.3. دو روش داره
12.6.1.3.1. Orchestration
12.6.1.3.2. Choreography
12.6.2. Composition یا API Gateway
12.6.3. CQRS (Command Query Responsibility Segregation)
12.6.3.1. Read Model & Write Model
12.6.3.2. When?
12.6.3.2.1. وقتی تعداد خواندن‌ها خیلی بیشتر از نوشتن‌هاست
12.6.3.2.2. مدل داده‌ای که برای نوشتن طراحی شده، معمولاً برای خواندن کارآمد نیست.
12.6.3.2.3. با جداسازی مدل خواندن، می‌تونی پایگاه داده‌ای بهینه برای کوئری‌ها انتخاب کنی. مثلاً از ElasticSearch برای جستجوی سریع استفاده کنی، درحالی‌که نوشتن‌ها رو روی یک دیتابیس رابطه‌ای انجام می‌دی
12.6.3.2.4. در سیستم‌های پیچیده، جداسازی مسئولیت‌ها باعث ساده‌تر شدن منطق کسب‌وکار میشه. چون نیازی نیست در یک بخش هم به خواندن سریع و هم به عملیات نوشتن رسیدگی کنی.
13. CAP
13.1. Consitency
13.1.1. هر کوئری به هر سرور بزنم نتیجه یکسان بگیرم
13.2. Avaailibilty
13.2.1. نود اگه تو حالت نان فیلینگ باشه یا ریکاوری مود نباشه باید بتونه ریسپانس بده
13.3. Partition Networking
13.3.1. اگه یه نود خارج شد بقیه نود ها بتونن کارشون رو ادامه بدن
13.4. CA
13.4.1. رو یه سرور هستیم و اگه سرور خراب نباشه همیشه جواب میده
13.5. CP
13.5.1. وقتی نتورک پارتیشن اتفاق بیفته همه سرور ها به حالت read میشن
13.6. AP
13.6.1. وقتی نتورک پارتیشن اتفاق بیفته همه سرور ها هم چنان read/write هستن
13.7. PACELC
13.7.1. وقتی نتورک پارتیشن اتفاق میفته شما مجبوری بین av و cons یکی رو انتخاب کنی در صورتی که اگه شرایط خوبه باید بین لیتنسی و کانسیستنسی یکی رو انتخاب کنی
13.7.1.1. سیستم ها یا
13.7.1.1.1. pc/ec هستن
13.7.1.1.2. pa/el هستن
14. برخی از اصطلاحات
14.1. floating point error: مشکل ذخیره سازی اعداد اعشاری به صورت باینری در کامپیوتر وقتی پیش میاد که استرینگ رو به فلوت تبدیل میکنی
14.2. ORM: یه روشه که پروگرمر رو از کوئری خام و مستفیم به دیتابیس زدن بی نیاز میکنه
14.2.1. مزایا
14.2.1.1. جلوگیری از sql injection
14.2.1.2. ساده سازی کار با دیتابیس
15. Databases
15.1. Mysql
15.1.1. پارتیشن کردن
15.1.1.1. کی خوبه ازش استفاده کنیم؟
15.1.1.1.1. وقتی جدولت خیلی بزرگه (مثلاً چند میلیون ردیف) و کوئری‌ها کند شدن.
15.1.1.1.2. وقتی جدول‌ها خیلی بزرگ میشن، کوئری زدن بهشون ممکنه کند بشه. با پارتیشن‌بندی، کوئری‌ها فقط روی پارتیشن مرتبط اجرا میشن.
15.1.1.1.3. وقتی نیاز داری مرتب داده‌های قدیمی رو پاک یا آرشیو کنی.
15.1.1.1.4. وقتی داده‌ها رو مرتباً تقسیم‌بندی‌شده استفاده میکنی (مثلاً بر اساس تاریخ، منطقه جغرافیایی، یا دسته‌بندی محصول).
15.1.1.2. کی خوب نیست؟
15.1.1.2.1. وقتی حجم داده‌هات کمه یا نیاز به پارتیشن‌بندی نداری.
15.1.1.2.2. وقتی اکثر کوئری‌هات روی همه داده‌ها اجرا میشه و تقسیم‌بندی بی‌فایده‌ست.
15.1.1.3. مزایا
15.1.1.3.1. اگر جدول سفارشات بر اساس تاریخ پارتیشن‌بندی بشه، وقتی دنبال سفارشات ماه دی می‌گردی، فقط روی پارتیشن دی جستجو میشه، نه کل جدول.
15.1.1.3.2. می‌تونی هر پارتیشن رو روی دیسک یا سرور جداگانه قرار بدی تا فشار روی یک سیستم کم بشه.
15.1.1.4. معایب
15.1.1.4.1. اگر کوئری‌ای بزنی که داده رو از چندین پارتیشن بخواد، ممکنه کندتر از یک جدول ساده بشه.
15.1.1.4.2. نیاز به آپدیت کردن داره که البته با اسکجولر میشه هندلش کرد
15.1.2. data types
15.1.2.1. blob
15.1.2.1.1. اگه بخوای فایل رو تو دیتابیس ذخیره کنی
15.1.2.2. CHAR vs VARCHAR
15.1.2.2.1. CHAR 255 VARCHAR 4000
15.1.2.2.2. CHAR is faster than VARCHAR.
15.1.2.2.3. طول ثابت: یعنی اگر شما یک فیلد CHAR(10) تعریف کنید، حتی اگر فقط 5 کاراکتر وارد کنید، MySQL بقیه فضا را با فاصله (Space) پر می‌کند. به عنوان مثال، مقدار Hello در یک فیلد CHAR(10) به صورت Hello ذخیره می‌شود. کاربرد: مناسب برای داده‌هایی که همیشه طول ثابتی دارند، مانند کدهای پستی، کدهای کشور یا کدهای محصول.
15.1.2.2.4. طول متغیر: یعنی اگر شما یک فیلد VARCHAR(10) تعریف کنید و 5 کاراکتر وارد کنید، MySQL فقط 5 کاراکتر را ذخیره می‌کند و بقیه فضا را اشغال نمی‌کند. به عنوان مثال، مقدار Hello در یک فیلد VARCHAR(10) دقیقاً به صورت Hello ذخیره می‌شود. کاربرد: مناسب برای داده‌هایی که طول آنها متغیر است، مانند نام‌ها، توضیحات، آدرس‌ها و مواردی که اندازه‌اشان می‌تواند متفاوت باشد.
15.1.2.3. byte < short < int < long (تا اینجا صحیح) < float < double < decmial < big decimal
15.1.3. noramalization vs denormalization
15.1.3.1. یه جاهایی حتی میشه 1nf رو هم نقض کرد و از set استفاده کرد و همه ی اینا با توجه به شرایطه که تصمیم میگیری چیکار کنی
15.1.4. **Constraints** are the rules that we can apply to the type of data in a table. NOT NULL - UNIQUE - PRIMARY KEY - FOREIGN KEY - CHECK - DEFAULT
15.1.5. clustered and non clustered indicies
15.1.5.1. Non-Clustered Index
15.1.5.1.1. داده‌ها به صورت جداگانه ذخیره می‌شوند و ترتیب فیزیکی جدول را تغییر نمی‌دهد.
15.1.5.1.2. چندین Non-Clustered Index می‌تواند در هر جدول وجود داشته باشد.
15.1.5.1.3. کندتر است زیرا نیاز به Lookup برای دسترسی به داده‌ها دارد.
15.1.5.2. Clustered Index
15.1.5.2.1. داده‌ها در جدول بر اساس این ایندکس مرتب می‌شوند.
15.1.5.2.2. فقط یک Clustered Index در هر جدول مجاز است.
15.1.5.2.3. سریع‌تر است زیرا داده‌ها مرتب هستند.
15.1.6. برای انجام عملیات زمانبندی‌شده می‌توانید از CREATE EVENT استفاده کنید:
15.1.6.1. CREATE EVENT my_event ON SCHEDULE EVERY 1 DAY DO INSERT INTO log_table (log_message) VALUES ('Daily log');
15.1.7. Stored Procedures
15.1.7.1. مزیتش اینه که امنیت میره بالاتر چرا؟ چون مثلا نمیخوای کلاینت به بعضی تیبلا دسترسی پیدا کنه
15.1.7.2. هر بار که اجرا می‌شوند، نیازی به کامپایل مجدد ندارند، بنابراین زمان اجرای آنها سریع‌تر است.
15.1.8. کش کردن کوئری تو نسخه ی 8 به بعد حذف شده
15.1.9. Data Integrity
15.1.9.1. فرض کنید یک پایگاه داده فروشگاه آنلاین دارید. اگر مشتری سفارشی ثبت کند
15.1.9.1.1. مشتری در جدول مشتریان وجود داشته باشد (Referential Integrity).
15.1.9.1.2. شماره سفارش یکتا باشد (Entity Integrity).
15.1.9.1.3. مبلغ سفارش عدد مثبت باشد (Domain Integrity).
15.1.9.1.4. فیلدهای ضروری مانند نام مشتری یا آدرس خالی نباشد(Completeness).
15.1.10. stored procedure => مثل یه فانکشن عمل میکنه که اینپوت میگیره و DML های مختلف انجام میده
15.1.11. sql injection => SELECT * FROM users WHERE username = '' OR '1'='1';
15.1.12. index
15.1.12.1. WHERE، JOIN، ORDER BY و GROUP BY
15.1.12.2. Selectivity(مقدایر یکتا) بالا
15.1.12.3. ایندکس روی ستون‌هایی با مقادیر کوچک‌تر (مثل INT یا VARCHAR(20)) سریع‌تر و بهینه‌تر از TEXT یا BLOB است.
15.1.12.4. حواسمون به فارن کی باشه که تو inodb ایندکس میشه ولی تو پستگرس نه
15.1.12.5. یه جایی فول تکست ایندکس مناسبه که از Inverted Index استفاده میکنه که کلمه های داکیومنت رو جدا میکنه و میگه هر کلمه تو چه داکیومنت هایی ذخیره شده
15.1.12.6. انواع
15.1.12.6.1. B-TREE
15.1.12.6.2. HASH
15.1.12.6.3. FULLTEXT
15.1.12.6.4. SPATIAL Index
15.1.12.6.5. UNIQUE
15.1.12.6.6. COMPOSITE
15.1.12.6.7. CLUSTERED
15.1.12.6.8. GIN و GiST Index
15.1.12.6.9. تصمیم گیری در خصوص ایندکس به نحوه ی استفاده از table مرتبطه و باید ببینیم چه کوئری هایی زده میشه و چه اوپریشن هایی داریم، همچنین میزان اوپریشن رایت و رید هم مهمه
15.1.13. انواع لاک
15.1.14. Explain Analyse
15.1.14.1. دستور رو اجرا میکنه
15.1.14.2. از داخلی ترین شروع میکنیم
15.1.14.3. query planner
15.2. normalization
15.2.1. 1nf
15.2.1.1. هر جدول باید یک مقدار در هر سلول داشته باشد
15.2.2. 2nf
15.2.2.1. همه ستون‌های غیرکلیدی باید به کل کلید اصلی وابسته باشند، نه بخشی از آن.
15.2.2.1.1. اگر یک جدول فاکتور از دو ستون "شماره فاکتور" و "کد محصول" به عنوان کلید اصلی استفاده کند، اما "نام مشتری" فقط به شماره فاکتور وابسته باشد، این نقض ۲NF است.
15.2.3. 3nf
15.2.3.1. هیچ ستون غیرکلیدی نباید به یک ستون غیرکلیدی دیگر وابسته باشد
15.2.3.1.1. اگر یک جدول شامل "کد مشتری"، "نام مشتری" و "آدرس مشتری" باشد، اما "آدرس مشتری" به "نام مشتری" وابسته باشد، این نقض ۳NF است.
15.2.4. 4nf
15.2.4.1. وابستگی چندمقداری نباید وجود داشته باشد (یعنی یک ستون نباید به دو مقدار مستقل وابسته باشد).
15.2.4.1.1. دانشجو دوره مهارت علی ریاضی جاوا علی ریاضی پایتون
15.2.4.2. ۴NF: اگر یک جدول شامل دو مجموعه داده مستقل باشد که به هم ربطی ندارند، آن را به دو جدول جدا تقسیم کن.
15.2.5. 5nf
15.2.5.1. ۵NF: اگر یک جدول را می‌توان بدون از دست دادن اطلاعات به چند جدول کوچک‌تر تقسیم کرد، این کار را انجام بده.
15.3. SQL
15.3.1. isolation levels
15.3.1.1. READ UNCOMMITTED
15.3.1.2. READ COMMITTED
15.3.1.2.1. ترنزکشن دوم تغییرات رو بعد از کامیت شدن میبینه
15.3.1.3. REPEATABLE-READ
15.3.1.3.1. ترنزکشن دوم تغییرات رو نمیبینه حتی اگه ترنزکشن اول کامیت شه
15.3.1.4. SERIALIZABLE
15.3.1.4.1. وقتی دو تا ترنزشکن باز میشن و یکیشون بخواد آپدیت کنه صبر میکنه تا بعدی کامیت شه بعد این کارش رو انجام بده وقتی یه ترنزکشن باز شده و یه تغییراتی میده ولی کامیت نمیکنه ترنزکشن بعدی تو select هم waiting میمونه
15.3.2. WITH RECURSIVE
15.3.2.1. پیدا کردن همه مسیرها از A به شهرهای دیگر.
15.3.2.2. **WITH RECURSIVE** FOO AS ( SELECT ... WHERE City = 'A' UNION ALL SELECT ... JOIN **FOO **... )
15.3.2.3. می‌خواهیم تمامی زیرمجموعه‌های یک مدیر خاص را پیدا کنیم.
15.3.3. diff beween ‘_’ and ‘%’
15.3.3.1. _ : جایگزین یک کاراکتر تکی است.
15.3.3.2. % : جایگزین صفر یا بیشتر از صفر کاراکتر است.
15.3.4. EXCEPT تفریق میکنه EXCEPT ALL به همون تعداد که در دسته ی دوم وجود داره حذف میکنه
15.3.5. delete شرط میگیره ولی truncate نه
15.3.6. INTERSECT وجه مشترک رو میاره
15.3.7. اگه بخوای یه تیبل رو کپی کنی create like میکنیش
15.3.8. Union تکراری ها رو حذف میکنه ولی وقتی Union All میزنی تکراری ها رو هم میاره
15.3.9. window functions
15.3.9.1. similar to an agg func, it performs the ops acrross multiple rows. Unlike an agg func, it doesn't group rows into one single row.
15.3.9.2. FUNCTION() OVER (PARTITION BY column ORDER BY column)
15.3.9.3. SELECT window_function() over (window_nane) FROM ... [HAVING ...] WINDOW window_nane AS (PARTITION BY column ORDER BY column) [ORDER BY ...]
15.3.9.4. we want to compare each product's price with the avg price of that year
15.3.9.5. ROW_NUMBER: پیدا کردن سه حقوق برتر در هر دپارتمان. DENSE_RANK, RANK: رتبه‌بندی فروش در هر منطقه - رتبه‌بندی دانش‌آموزان در یک کلاس SUM: محاسبه جمع کل برای هر گروه AVG: محاسبه میانگین مقادیر برای هر گروه COUNT: تعداد کارمندان در هر دپارتمان LAG: مقایسه یک مقدار با مقدار قبلی - بررسی تغییرات فروش نسبت به ماه قبل LEAD: مقایسه یک مقدار با مقدار بعدی CUMULATIVE SUM (SUM با Frame): جمع تجمعی فروش در هر ماه FIRST_VALUE - LAST_VALUE: پیدا کردن حداقل و حداکثر مقدار - حقوق حداقل و حداکثر در هر دپارتمان CUME_DIST - NTILE - PERCENT_RANK هم برای محاسبات آماری پیشرفتن تفاوت بین ROW_NUMBER() و RANK(): تابع ROW_NUMBER() یک شماره ردیف منحصر به فرد برای هر رکورد در مجموعه نتیجه برمی‌گرداند، اما RANK() رکوردهای مساوی را با همان رتبه رده‌بندی می‌کند و بعد از آن رتبه‌ها را می‌پریزد.