DatPT dattp

Requirement

Flow:

Bài toán thống kê học sinh nghỉ học

thống kê số học sinh nghỉ học có phép, nghỉ không phép.
đầu ra: thống kê theo toàn bộ sở, phòng giáo dục, trường học.
ví dụ: nếu thống kê các trường cấp 3 của sở HN, thì trả về 1 ds các trường ở HN đã điểm danh dữ liệu bao gồm: tổng học sinh, hs nghỉ có phép, hs nghỉ không phép.
có 2 tính năng đang tác động đến thống kê này: đơn nghỉ học, và điểm danh lớp học.
Mỗi khi có đơn xin nghỉ phép từ PH => GV, GV duyệt đơn => hs nghỉ có phép.
Mỗi khi giáo viên điểm danh HS là nghỉ có phép => hs nghỉ có phép. Điểm danh học sinh nghỉ không phép => ds nghỉ không phép.


	# Install dependencies only when needed
	FROM node:18-alpine AS builder

	WORKDIR /app

	RUN apk add --no-cache libc6-compat && rm -rf /var/cache/apk/*

	ARG NEXT_ENVIRONMENT

	import {
	Schema, model, Document,
	} from "mongoose";
	import { IAsset } from "@type/asset.type";

	interface AssetDocument extends IAsset, Document {
	transform(): string
	}

	const schema = new Schema<AssetDocument>({

	### Stateless và statefull

	Hiểu đơn giản thì `stateless` nó là 1 cái gì linh hoạt. Còn `statefull` thì nó sẽ ràng buộc với 1 cái gì đó.
	Ví dụ: về vấn đề scale service.
	* Deploy service application trong 1 cụm swarm. Khi có 1 service bị quá tải, ta sẽ chạy thêm service đó trong cụm swarm bằng lệnh `docker service scale service = 5` lên 5 service. Việc scale service diễn ra nhanh gọn, không cần chỉnh sửa config vì cả 5 con chạy lên cùng 1 port expose, gateway sẽ tự chia tải đều.
	* Vẫn là trong cụm swarm đó, nhưng nếu là service chạy socket.io. Vì dữ liệu từ client gửi lên được lưu trong từng service. Nên với mỗi request từ client gửi lên. Ta cần cho nó vào 1 service duy nhất mà trc đó nó đã vào. Nếu nó vào service khác thì dữ liệu gửi lên trc đó không tồn tại (ăn theo từng process của request). Do vậy, việc scale service diễn ra ngay từ khi config deploy- xác định rõ số lượng service cần chạy, và mỗi service chạy trên 1 port riêng. Do đó, ngay từ confix của revert proxy (HAproxy) đã phải config cho ws theo kiể

	#### Cải tiến cho ứng dụng chat
	* Đổi những event mà socket đang on sang api. Ví dụ như nhận tin nhắn `gui_du_lieu_chatting_guid` chuyển sang gửi tin nhắn bằng api.
	* Tạo ngay `_id` trong mongo, emit socket về client và thực hiện insert tin nhắn sau.
	* Tạo thêm 1 field `slug` trong bảng tin nhắn để phục vụ việc search không dấu.
	#####################################################################################################################################
	* handle khi sử dụng các tính năng search, ghim, bấm vào tin nhắn gốc replied.
	* làm lại cơ chế skip, limit khi lấy list tin nhắn (sửa luôn các api khác cũng làm theo cơ chế này)
	* phân trang theo cơ chế seeking. Dữ liệu get list ở API phải trả về thêm giá trị next cursor và pre cursor.
	* trong đó next cursor sẽ là id của message `cuối cùng trong list` và pre cursor sẽ là id của message `đầu tiên trong list` (chỉ đang đang tính list trả về).
	* giải pháp phân trang ở đây sẽ là đứng ở vị trí của next cursor (id mesage) và lấy tiế

	* bản chất join trong sql
	* cơ chế join trong sql phụ thuộc vào thuật toán được sử dụng khi join.
	* sử dụng câu lệnh `explain` để xem chi tiết khi join.
	* có 3 thuật toán phổ biến khi join: `nested loop`, `hash`, `sort merge`
	* `nested loop join`:
	* thực hiện so sánh tất cả các rows trên 2 table.
	* duyệt qua từng row của 1 table.
	* với mỗi row duyệt qua từng row của table còn lại.
	* với mỗi lần duyệt như vậy thì phép so sánh ở lệnh `ON` sẽ được sử dụng.
	* => thuật toán đơn giản, nhưng phức tạp về thời gian thực thi.

	/*
	* To change this license header, choose License Headers in Project Properties.
	* To change this template file, choose Tools \| Templates
	* and open the template in the editor.
	*/
	package project1;

	/**
	*
	* @author Desktop