개발할 때 이런거 쓰지말라고 몇번을

Рет қаралды 198,308

코딩애플

Жыл бұрын

블루 아이즈 화이트 드리즐
드로우 잘하는 법 codingapple.com/
일반강의 10% 할인 쿠폰 : GPT5 (맨날 바뀜 최신영상 참고)

Пікірлер: 193

@user-od4tp6hc6z Жыл бұрын

항상 재밌고 신기한 기능들 소개해 주셔서 감사합니다 ㅎㅎ

@jooh_lee Жыл бұрын

드리즐 칭찬세례라며 보여준 영상에 드리즐 칭찬이 단 하나도 없는 저 당당함 너무 멋지다

@alpakasynergy Жыл бұрын

I hate drizzle 😂😂😂😂😂😂😂😂😂😂

@hcypher6893 Жыл бұрын

"님들 걍 Eloquent에서 다 베껴오쇼"

@yooo1212 Жыл бұрын

회사가 싫을 때 프리즈마를 난잡하게 쓰면 되겠군. 편리하면서 회사에 부하를 많이 주는

@Radian94 Жыл бұрын

지금 투입될 플젝에서 graphql이랑 프리즈마 조합하고 있어서, 프리즈마 리서치 할라했는데 딱 이 영상이 나왔네유 흐흐

@user-oo2wb8tf7i Жыл бұрын

선비 사진 개웃기네 ㅋㅋㅋ

@hoyakim4280 Жыл бұрын

그리고 이걸 인수받은 후임 개발자는 유지보수 불가를 선언하고 드러누워 버리게 되는데...

@necromansir6060 Жыл бұрын

이분 없었으면 심심해서 어떻게 공부했어..진짜

@chy6288 Жыл бұрын

있구요~ 같고요~ 것이구요~ 없구요~ 이에요~ 저는 이 말투가 너무 좋아서 구독했어요 ㅎㅎㅎㅎ 코딩은 하나도 모르지만,.. 😇😇😇

@Kyamicho 24 күн бұрын

이 말투 처음엔 거슬렸는데 들으면 들을 수록 뭔가 중독되고 빠져듦... 상술에 넘어간걸까요

@crlayh Жыл бұрын

알고 쓰는거랑 모르고 쓰는거랑 많은 차이가 있지만, 요즘은 그냥 모르고 편하니깐 쓰는 사람이 많은거 같네요… 게으른 개발자😂😂😂

@xxxyyyzzz612 Жыл бұрын

대단하다! 자바 개발자들과 자바스크립트 개발자들은 그냥 곧바로 풀 스택 개발자가 되네!

@jongmin0328 Жыл бұрын

직접 SQL 던지면 물론 성능이야 훨 빠르겠지만, 결국 타입도 직접 만들어야 되고, 서비스 로직과 상관없는 불필요한 코드가 너무 많아짐. 코드에 DSL 구문이 들어가는 것도 맘에 안들고, 딱히 마이크로초 단위의 속도차이를 신경쓰는 서비스 아니면 ORM 써서 만드는 것이 생산성 측면에서 낫다고 봅니다.

@user-bv8zm3fp5c Жыл бұрын

형은 왜이리 똑똑해 나도 형의 뇌를 갖고싶다

@bluegreen6121 Жыл бұрын

지금은 모르겠는데 join 이나 union 등 복잡한 쿼리는 어차피 sql사용해야합니다. 차라리 knex가 나아요.

@user-vh6tt2vi2v Жыл бұрын

Rust도 소개해주시면 좋을 것 같아요!

@yareach-ayla 3 ай бұрын

이 영상 처음 볼 때는 그러려니 했습니다. 그러다 (자바스크립트는 아니지만) 스칼라 라이브러리인 Slick을 알게 됐는데 신세계더라고요. 프리즈마 같은 라이브러리도 DB종류가 바뀌어도 SQL문 수정 안해도 된다거나 언어에 맞게 직관적으로 쓰인다거나 하는 점 때문에 잘 쓰면 SQL보다 좋을 것 같기도 합니다.

@sjsjsjsj5225 4 ай бұрын

DB 구조가 특이하거나 view 쓰거나 멀티DB구조 사용하거나 복잡한 쿼리 쓰려고 할때 orm 쓰면 문제가 많이 생겨서 결국에 돌고돌아 sql로 돌아옴 ㅠㅠ 어차피 ORM이라는게 모든 종류의 DB의 모든 기능을 대응하지는 못하고, 복잡한 쿼리 쓰려면 ORM 학습을 따로 해야되는데 그냥 공용언어인 sql 한개만 잘 배워서 물고뜯고즐기는게 좋은것 같네여

@Rhu_Vaeruxia Жыл бұрын

현재 유사한 코드를 학원에서 배우고 있어 놀랬네요.

@js__k984 Жыл бұрын

내가 담당하는게 단순한 데이터 CRUD 면 공부 안하고 쓰면 되나... 데이터와 점점 가까운 롤을 할수록 제약도 많고 ORM 내부 동작도 알아야 되고 당연히 SQL 은 원래 알아야 하는 만큼 알아야 됨

@kennyyeo2244 8 ай бұрын

영상에 다 나오지만 타입스크립트 타이핑 자동완성으로 테이블 뒤질필요 없다는게 장점이죠. 생쿼리로 되는게 있음 저좀 알려주세요.. 그리고 편함이 성능을 담보로 하는게 말이 안된다고도 언급하셨죠. 쿼리 당연히 알아야 하고요. 성능 신경쓰는 단계는 이미 편함이 목적이 아닐거 같네요.

@_kyaru Жыл бұрын

orm이 양날의 검인게 라라벨에서 엘로퀀트 쓰고있는데 성능이 너무 최악.. 컴퓨팅 파워로 밀면 되는데 프로파일링 하면 타입 캐스팅, 필터에서 너무 리소스 먹어요..

@gbchoi6983 Жыл бұрын

에픽게임즈에서 얼마전에 발표한 VERSE에 대한 애플코딩님 생각이 궁금합니다! kzbin.info/www/bejne/g5nMhJpoe8lrp8k

@kuitar2615 Жыл бұрын

떼잉 쯧 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 진짜 얼척없게 웃기네

@user-vm2kq1fu1i Жыл бұрын

와 진짜 코딩애플 영상 대단하네요.

@seongsikkim9705 10 ай бұрын

db 튜너입장서는 최악의 라이브러리입니다. 디비성능은 모르겠고 결과만 나오면돼 이럴때 쓰는게 orm입니다

@user-rb6dx1zr8t Жыл бұрын

현직에서 nest와 같이 쓰는 prisma가 나와서 신기합니다 질문 안받음

@vankuship8362 6 ай бұрын

프리즈마 메모리 누수 때문에 3개월 고생한 입장에서 ㅋㅋ 감사합니다

@user-in5ii5kk7k Жыл бұрын

지렸다

@sheep3393 11 ай бұрын

전 모델을써도 Create 빼고는 전부 raw sql로 씀.. 조회속도가 성능차이가 확연히 남

@__enigma Ай бұрын

"Your 0 user unicorn service"를 위해 "blazing fast"하는 걸 추구하느니 본인한테 맞는 툴로 실제 생산에 집중하는 게 좋다고 생각합니다 ㅋㅋ

@jumping-wolf Жыл бұрын

복잡한 쿼리는 직접 만들어야 하지만 왠만한 건 orm으로 돌리는 게 생산성이 확실히 좋습니다 매우 편함

@hyeonsu-hl2ff Жыл бұрын

간단한것도 그냥 sql로 짜면 되는거아님 그러면..? 복잡한건 쌩 sql로 짜고 간단한건 orm 처리하고 그러면 통일성 깨져서 더 복잡하겠다 ㅋㅋㅋ

@qwertyjon6155 Жыл бұрын

@@hyeonsu-hl2ff 그 복잡한게 ㄹㅇ 복잡한 통계쿼리같은거아니면 어지간하면 처리될거에요

@qwertyjon6155 Жыл бұрын

@@hyeonsu-hl2ff 통계쿼리만 준내써야하는 프로젝트면 걍 sql매퍼쓰는게 맞고

@Woong654 Жыл бұрын

@@hyeonsu-hl2ff 간단하게 구현하는게 orm의 핵심이 아니고 데이터베이스도 객체지향적으로 다루기 위해서 사용하는게 orm입니다. 이를 위해서 테이블 설계부터 객체지향작으로 쌩sql 쓸 때랑은 다르게 해야 orm의 참맛을 느낄 수 있습니다.

@jumping-wolf Жыл бұрын

@@hyeonsu-hl2ff db 스펙 바뀌는 상황에서는 단순 문자열로 들어가있는 sql로는 오류 잡기가 매우 까다롭게 다가올 겁니다 런타임 오류가 아닌 컴파일 오류로 해결할 수 있다는 장점이 가장 커요

@feeeeeeeeeeder8108 10 ай бұрын

이것도 4개월전 이야기가 되버렸다

@LarkGarry 11 ай бұрын

이미 고장나버린 뇌입니다.

@jinhanchang Жыл бұрын

프리즈마 개발 편하고 좋았음

@KimCoder_ Жыл бұрын

영상을 보니까 편해보이는데 영상 제목 처럼 저는 그냥 SQL 문법이나 다시 쳐볼게요

@SLHA Ай бұрын

typeorm 너무 느려서 걷어내려고 하던데, 성능이 중요하다면 그냥 knex처럼 간단한 쿼리빌더 쓰는게 맞는거 같아요..

@alnori_gun 8 ай бұрын

구라 조인이라 써있는거 보고 빵터졌네요 ㅋㅋㅋㅋ

@jeremyko1765 Жыл бұрын

orm 경험 하고나서 절대로 하면 안되겠다고 다짐하게 되었습니다. 조금만 복잡한 join 등이 들어가게 되면 차라리 생 sql 이 훨씬 훨씬 직관적으로 의도를 알수 있어요. 그런데 orm 사용하면 아주 간단한 sql 이면 모를까 , join 들어가고 복잡해지면 나중엔 짠 사람도 혼란스럽습니다. 나중에 유지 보수 차원에서도 헬이 됩니다. 절대 비추함

@popjiggly Жыл бұрын

0:34

@user-dz6xj9ic4g 11 ай бұрын

@@popjiggly type transfer가 어려움?

@IlllIlIlllIIIllIl 9 ай бұрын

평생 자바 1.8이나 노 프레임워크 PHP, 워드프레스, 그누보드만 하실거 같은 분

@p4rk5h 9 ай бұрын

@@IlllIlIlllIIIllIl 저걸 쓴다고 그러면 Query Complexity 가 낮고, Automatic Migration 이랑 typing boilerplate 제거 목적 (특히 typing과 DB Schema와의 drift 최소화 하려는 목적) 이 큰데, 애초에 쿼리 엔진을 두번 타는 입장에서 애초에 저 prisma로 Performance를 기대하거나 Real-time CRUD 같은거 하라고 만든건 절대 아닌 거 같은데? 그냥 조금 더 복잡해진 CMS에 필드같은거 유동적으로 변할 일 많을 때 쓰라고 만들어진 느낌? (물론 이런건 conventional CMS 에서들도 되는 거긴 하지만, 그건 더 느려터졌으니까 애초에 prisma 랑 비교 대상이 아니라고 생각함) 그리고 ORM 쓰는 경우는 어짜피 객체로 이미 관리를 해야 하는 상황에서 모델 마다 필요한 "기능" (예. 님이 말한 JOIN 탐색 같은거) 들을 Mapping 에 추가 하는 방향으로 가는 건데 (prisma 는 이딴거 안되니 솔직히 ORM 이라고 불러도 되는지 모르겠음. (쓸려면 Wrapper 만들어야 되는 데 그러면 ORM 왜 씀 (typing drift 문제 재발)?) 그냥 저건 Query/Type Builder with Automatic Migration 이지) Relation 끼리 탐색하는 게 어렵다고 하면 대체 어떤 ORM 을 쓴건지는 모르겠지만 진짜 prisma 같은 유사 ORM이거나 ORM 반쪽짜리만 써본듯" 애초에 퍼포먼스가 중요한 곳이면 이미 회사 내에 DBA가 있을꺼고, DBA가 내준대로 쓸테니 애초에 prisma 를 쓸 일도 없음.

@user-er5tq9gj4b 8 ай бұрын

네 다음틀

@NIHILncunia Жыл бұрын

프리즈마 솔직히 너무 편함..

@hj11111 Жыл бұрын

선비 사진 보고 나인줄 ㅋㅋ

@user-fd7kb9qy6y 11 ай бұрын

말하는게 존나 발표잘할거같아.....

@wontaekim7536 Жыл бұрын

주니어 백엔드로 시작하려는 분들에게 한말씀 드리면.. SQL 부터 적당히 CRUD join 능숙하게 사용할 정도는 알아두시고 ORM 파시는게 실무에도 취업에도 도움이 될거라고 생각합니다.

@bboung1004 Жыл бұрын

으... 꼰대

@노나메 Жыл бұрын

@@bboung1004 으... 잼민

@museaang Жыл бұрын

근거는?

@bwshin413 Жыл бұрын

@@museaang 항상 새로운 프레임워크나 최신 버전들 이용해 개발하는 환경에서 일할거 아니면 SQL 문법 실무에 쓰는곳도 여전히 엄청 많고, 결국 이직할때도 상대는 레거시 프로젝트만 오래한 경력자면 레거시 중심으로 기술면접할 확률이 큼 이럴때 ORM 기반으로만 작업 해봤으면 따로 복습해서 가는거 아니면 꽤 햇갈릴 수 있음

@user-vn8zh8oy7w Жыл бұрын

당장 영상에도 있는 내용인데 orm이 마냥 만능이 아님. 개발중에는 이슈가 없었고 기능적으로 오류도 아니지만 n+1같은 재앙적인 성능이슈가 날수도 있음. 대응이 가능한 기능이 orm내에 있다할지 언정 db에 대한 최소한의 지식이 있어야 트러블슈팅이 되고 대응하는 방법을 찾을수 있음

@eing4424 Жыл бұрын

몽타뉴..몽구스.. 중얼중얼...

@PAD__Milriver 9 ай бұрын

(방패)

@rockeysLife 6 ай бұрын

핵심은 소규모 프로젝트나 프로토타입에서는 유용한 정도지만, 실제 서비스를 생각하는 부분에서는 좋지 않은 선택이다. 제 개인생각.

@sfp7568 Жыл бұрын

이 영상은 ORM의 반의 반만 설명한 거네요. 뭐라고 해야할까요.. '단순 CRUD작성은 매퍼 작성하기 귀찮으니 프로젝트 초기에는 ORM을 써서 생산성을 높일 수 있다..' 정도로 정리하면 될듯요. 프리즈마가 어디까지 구현이 되어있는지 모르겠지만 간단한 where절에도 저렇게 SQL 키워드가 들어갈 정도면 그냥 안쓰는게 낫습니다..; 저는 프리즈마를 이 영상으로 처음 접했습니다.

@user-dy9ym6li1g 7 ай бұрын

ㅋㅋㅋ 0:29 sql 근본주의자

@user-ec1gw2th3f Жыл бұрын

그냥 gpt에게 물어보면되잖슴

@inni.c Ай бұрын

찬양하라 JPA

@he1410 Жыл бұрын

sveltekit을쓴다면?

@ants33333 4 ай бұрын

내 집안에 TV가 있으니 아무나 다 가져가세요 이런건가ㅎㅎ 은행에서 이런거 쓰면 재미있겠네요 개발자가 뇌없으면 저런걸 쓸듯

@user-yz1li5rc7i Жыл бұрын

아 자꾸 orm쓰지 말자구요 네...?! 잘쓰던가...

@chdlsp 5 ай бұрын

소신발언: prisma니 jpa니 SQL 못하는 멍청이들이나 좋아하는 사파 야매 도구

@carllis Жыл бұрын

그럼 저거 3개 합치면 융합도 되는거야?

@catjin2791 Жыл бұрын

공격력 4500이냐고 ㅋㅋㅋㅋ

@cond_b Жыл бұрын

얼티멧토 브루 아이즈 화이토 도래곤 ㄷㄷ

@minseokwon6484 Жыл бұрын

합치는 순간부터 일하실때 큰 소리로 듀얼! 외쳐야 컴파일링 됩니다~

@user-pv8ro6ff9i Жыл бұрын

u activate my trap card

@youtubebnb Жыл бұрын

듀얼이 컴파일인 언어.. 매력적인데..?

@golf-and-surf Жыл бұрын

틀딱용 mybatis hibernate 부터 ror 등등 orm은 꾸준히 나왔었는데 결국 복잡한 관계가 되고 고도화가 되다보면 쌩 sql만 짜게댐. 그러면 다시 딜레마에 빠짐. 으잉 쉽게 쓸라고 orm 했는데 왜 난 요즘 sql만 짜고있지? 이럴거면 퍼포먼스 내다버린 orm 애초에 안쓰는건디?

@train-to-yongsan Жыл бұрын

spring에 jpa+querydsl 쓰는 개발자로써 쌩 sql은 이제 못 쓰는 몸이 됐지만, 가끔 orm이 짜증날땐 jooq 같은 걸로 타협하고 싶을 때가 있음

@user-hu4yx8mq1i 8 ай бұрын

넥스트14에서 sql 프론트에 쳐박아놔서 이제 쓸모없네요 ㅅㄱ

@user-fe6fz3gm9i 11 ай бұрын

문과 함유량 1200% 외고생인데 이거 왜보고 있냐

@user-ec5oc8ku5z Жыл бұрын

prisma 쓰려고 했는데 이런 문제가...

@Frost-1209 11 ай бұрын

그래서 개발할 때 Prisma를 왜 쓰지 말라는 건가요? 그게 궁금해요. 3:40 서버리스 환경에서 딜레이 때문에 그런거에요? 잘 모르겠어서 답변 바랍니다. 처음엔 안써봐서 편해서 좋다! 라고 생각했는데 와... 4:26 예상외로 너무 느려지는데...;; 안정성만 따진다면 뭘 추천하시나요?

@user-cx5nb7du9w 11 ай бұрын

현업에서 안쓰는게 가장 큰 이유인듯

@mion- 6 ай бұрын

사용하셔도 됩니다. 서버리스 콜드스타드 이슈도 해결 되었고, 대규모 투자 받고 있어 성능 향상도 이뤄지고 있습니다. prisma 릴리스 히스토리 보시면 영상에서 지적하는 이슈들 해결해 나가고 있는걸 확인하실 수 있어요. 저희 회사는 Typeorm 사용하는데. 0.2 버전을 사용하고 있는데 그냥 쓰레기입니다.. ㅠ

@user-fu7zc2sc5v Жыл бұрын

무지성 typeorm만 쓰고 있었는데 댓글들 보니 배울 게 많네...

@user-bp5zs2ru1w Жыл бұрын

읽어보니 칭찬이 아닌데...?

@han6945 Жыл бұрын

타입스크립트요? 목을쳐라!!

@jagdishsama4085 Жыл бұрын

0:17 그냥 sql쓰자 ㅠㅠ 그거 학교에서 배웠잖아

@gmd317 Жыл бұрын

sql 이 쉽고 편한데 .... 크흠

@byunghotv Жыл бұрын

프리즈마 쓰는데 진짜 스프링에서 JPA쓰는거같아여

@yullivan Жыл бұрын

프리즈마로는 JPA처럼 OOP하기가 힘들어..

@iamcarrot9024 Жыл бұрын

@@yullivan 프리즈마 홈페이지가보면 JPA처럼 제공하는 연관관계 만드는 방법 많이나와잇음

@IlllIlIlllIIIllIl 9 ай бұрын

프리즈마보단 typeorm이 JPA 랑 비슷하죠 .. 그리고 프리즈마도 레포지토리 클래스 직접 만들어서 쓰시면 됩니다.. 단순히 예제 별로 없어서 OOP 하기 힘들다고 하시는건 좀..

@ottogibob 9 ай бұрын

자바...스크립트가 어딨죠? 그리고 으으디 SQL 놔두고 ORM 따위를... 에잉 쯧...

@mwoleuba8430 10 ай бұрын

prisma JOIN 개같이 하는거보고 바로 typeorm 쓰게됨

@user-ct5kt1pn9k Жыл бұрын

kzbin.info/www/bejne/boXRhn58qJKtfpI 분명 Drizzle 칭찬이라 돼있었는데 첫 댓부터 I hate Drizzle...

@user-xn1vz9jq1b Жыл бұрын

실제 공홈에 있는 화면인데, 밈 느낌으로 그냥 박아놓은 거 같음

@couquedasse3217 Жыл бұрын

4:47 뭐야 칭찬이 없잖아요

@yubinshin2282 Жыл бұрын

선생님 recoil도 영상 만들어주실 생각 없나요 요즘써봤는데 너무 편해서요

@sdaqkr3392 Жыл бұрын

리코일 담당 개발자 퇴사해서 아마 유지보수어려울거 같다네요…ㅠㅠ

@user-tp9wu8ey8n Жыл бұрын

@@sdaqkr3392 아니 진짜요? 에반데

@user-tp9wu8ey8n Жыл бұрын

@@sdaqkr3392 그럼 뭐써야하죠..ㅠ 몹x?ㅠㅠ 리덕스는 싫은데 진짜..

@sdaqkr3392 Жыл бұрын

@@user-tp9wu8ey8n 유튜브 댓글은 링크 다 막히는군요..

@sdaqkr3392 Жыл бұрын

@@omg0000 3월달 글이긴한데 네이버에 recoil 개발자 치면 블로그에 글나와요

@user-gt7zr5nx8q 7 ай бұрын

코딩 안하는데 말투가 재밌네

@diosmio3931 Жыл бұрын

자바스크립트계 JPA 같은건가여??

@IlllIlIlllIIIllIl Жыл бұрын

typeorm이 jpa랑 똑같이생겼습니다

@iyaaaaaaaang Ай бұрын

파이썬 배우고 있는데 뭔 말인지 모르겠어요!

@user-ql1un2uw5f Жыл бұрын

난 자바스크립트가 싫어요..ㅠㅠ

@Vmann777 Жыл бұрын

너무 좋은데?

@mion- 6 ай бұрын

콜드 스타트 지연 이슈 지금 해결 됐습니다.

@user-ec1gw2th3f Жыл бұрын

orm이뭐에용?😂

@user-ff4mc6wn9e Жыл бұрын

몽타뉴 뭔데 ㅋㅋ

@hamter_Kong Жыл бұрын

ㅈㄴ 편함 ㅇ

@user-qq3pv4ph5j Жыл бұрын

와

@user-nc1nm3lh4p 10 ай бұрын

모르겠고 jpa 쓰세요

@gyeommyu Жыл бұрын

엑조디아를 만들자

@user-tl1vm8ch5w Жыл бұрын

이럼 레코드 암복호화 앞단에서 하나

@djha1257 Жыл бұрын

자바스크립트 너무 싫은데 잘나가서 짜증남

@unter_ 9 ай бұрын

php 보는 느낌이 갑자기 드는데

@user-en5se5hj6g 10 ай бұрын

이거 뭔지 모르겠어영

@gtdggtdg Жыл бұрын

JPA?

@user-sn8ii5wp5y Жыл бұрын

에엥..쯧

@kennyyeo2244 8 ай бұрын

그래서 제목은 왜 그런건가요 ㅋㅋ 쓰라는건지 말라는건지 어그로인가요 ㅋㅋ

@junggooon Жыл бұрын

내가 예민충인가 현업에서 ; 있다 없다 하는거 너무 킹받음..

@jung-holee3675 Жыл бұрын

그냥 mongodb를 쓰는 것도 괜찮을듯.

@IlllIlIlllIIIllIl Жыл бұрын

메인디비로 몽고디비는 제발 자제좀.....

@super-pig00 11 ай бұрын

@@IlllIlIlllIIIllIl왜요?

@user-bs5hw8ug4r 8 ай бұрын

@@super-pig00 프로젝트 규모와 경우에 따라 다른긴한데 한 컬렉션에 같은 필드에 row별로 타입이 다르게 들어간다는것만으로도 개발자 입장에서 굉장히 골때는 무수히 많은 경우가 생길수 있긴해요 하는 일 특성상 지속적으로 몽고를 쓰는데 제가 느낀건 때려 넣을때는 참 편한데 넣은 데이터를 나중에 꺼내서 어딘가에서 쓰게 될때 골때리는 경우가 종종있어요 아직은 주니어지만 짧은 경험바탕으로 공유 드려요

@ohmygod607 8 ай бұрын

아 댓글 너무 재밌다. 꼬꼬마들 어디서 주워들은 건 있어가지고 한마디씩 하네.

@gyuray Жыл бұрын

언젠가 비휘발성 메모리 접근 속도가 수 ns로 빨라지고 가격이 HDD만큼 저렴해지면 이런 골때리는 RDB/ORM 기술들도 없어지겠죠?

@aidenlim2750 Жыл бұрын

말씀해주신거랑 ORM은 전혀 상관이없는거같아요

@jaylee8669 Жыл бұрын

어디서 주워들은건 있는데 뭔지는 모르고 있는척 하고 싶으신가요

@imachomanjewelry Жыл бұрын

absolute search 속도가 빨라지면 작업할 때 편한 orm 쓰는 경우가 더 많아지면 많아졌지 사라질 일은 없을듯

@gyuray Жыл бұрын

ORM이 주 메모리 계층에서 데이터를 다루는 객체와 보조 메모리 계층에서 데이터를 다루는 DB 사이의 패러다임 차이를 매꿔주는 기술인데, 미래에 메모리 용량과 속도의 트레이드 오프가 해소되고 메모리 계층 구조가 일원화 된다면 계층 간 중간 다리 역할을 하는 매핑기술인 ORM도 필요 없어지지 않을까 생각했던 걸 적어봤습니다. 제 짧은 식견을 정정해주시면 감사하겠습니다.

@jaylee8669 Жыл бұрын

@@gyuray 오 끝까지 허세...