SQL을 ORM을 바꿔주는 걸 만드는 건 어때?
사이드 프로젝트를 하고싶지만 아이디어가 없는 나에게 JK가 저 말을 던졌다
Django 할 때 ORM을 접한 나같은 라떼들은 SQL로 짜는게 더 편해서 Model.objects.raw() 나 DB에 접속해서 execute하는 방법으로 생 SQL을 사용해본적이 있을 것이다 😏 (나만그래?)
근데 ORM도 익숙해지면 오히려 SQL보다 더 편하게 쓸수있다!
(지금의 리미는 ORM만 쓰도록 노력중이다!)
프로젝트 제목 : SQL To Django ORM
프로젝트 기간 : 2020.06 ~
License : MIT (오픈소스 한번 만들어보고 싶었다!)
GitHub : https://github.com/rimi-dev/sql_to_orm
1) SQL 구조를 보자
보통의 SQL이라 함은 이렇게 구성되어있다.
여기서 RIGHT OUTER JOIN 을 어떻게 할것인가에 많은 고민을 하였다.
Django ORM은 보통의 방법으로는 RIGHT OUTER JOIN 지원하지않고,
INNER JOIN과 LEFT OUTER JOIN(이것도 related name을 이용해서)가 가능할 것이다.
굳이 난 RIGHT OUTER JOIN 쓰겠어! 한다면, 본테이블과 RIGHT OUTER JOIN 된 테이블의 순서를 바꾸어서 가능할 것 같은데, 굳이 이런거까지 구현을 해줘야해?
FULL OUTER JOIN은 솔직히 저거 적을때 찾으면서 알았다 왠지 ORM에 없을거같은 느낌
데이터베이스를 뭘 쓰느냐에 따라 SQL이 달라지는데(내장함수 같은거...),
SQL은 최대한 W3Schools를 참고하여 구현하도록하겠다.
And 나의 뇌피셜
https://www.w3schools.com/sql/default.asp
2) 기본적으로 지원할 기능
일단 최우선으로 만들 기능을 정리해보자
기본적인 SELECT, FROM, ORDER BY 는 간단하게 구현하고
JOIN, WHERE, GROUP BY 순으로 일단 크게 나누는 것부터하고 GROUP BY쓸때만 사용하는 HAVING을 구현 후 CASE, LIKE, AND, NOT처럼 SELECT 문이나 WHERE문에서 사용하는 작은 함수들을 처리하도록한다. 그러고 UNION을 처리하도록한다!
아마 사이트 라이브는 JOIN 기능이 완료되었을때 부터 생각하고 있는중이다.
지금 고민 좀 해봐야되는 문제
- Django FK를 생성할시 column name을 따로 지정해주지않으면 이름 뒤에 "_id"가 붙게 되는데, 이걸 따로 설정을 만들어서 일괄처리 할 수 있게 만들것인지? 사용자가 지정했을때는 어떻게 할것인지? (db_column 사용시)
- RIGHT OUTER JOIN의 지원
FULL OUTER JOIN의 지원--> 많이 사용하지않을뿐더러 ORM만으로 처리가 불가능할 것 같음- LEFT OUTER JOIN를 사용하기위해 related name을 이용할때의 처리
- Django migrate를 칠 경우 Table 이름은 "앱명_소문자모델명"인데, 이걸 받아서 어떻게 처리할 것인지
(예: university 앱에 모델이 Reservation이 있다면 Table명은 university_reservation로 되는데 SQL로만 받으면 모델명이 Reservation인지 ReSerVation인지 알도리가없음)
3) 구문분석(Syntax Analysis)?
구문분석을 이용하는게 더 공부가 될거라는 의견이 나왔다
물론 공부를 하기위해서 하는 프로젝트지만,
아직 구문분석에 대한 탄탄한 이론이 갖춰져있지않은 상태라(한달 프로젝트로 보고있으므로)
일단 나의 방식대로 만들고 나서 하는 게 더 공부가 될 것 같다고 생각한다.(프로삽질러)
4) Devops
AWS Elastic Beanstalk를 사용해보려고 한다.
Docker도 한번 써보고 DevOps쪽은 약한 편이라
일단 라이브 시키는 건 JOIN을 만들고나서 하는걸로..
