[제안 or 의견] 테이블명을 varchar(20)으로 규정한 이유가 있을까요? 정보
[제안 or 의견] 테이블명을 varchar(20)으로 규정한 이유가 있을까요?
본문
아무 생각 없이
짧은주소를 더 정확하게 보여줄 필요가 있다고 생각해서
테이블명(bo_table)을 좀 길게 작성하고 작업하다 보니 에러가 나오네요.
bo_table 종류가 varchar(20)으로 되어 있어서 긴 테이블명이 잘렸던 것이었습니다.
검색해보니 2003년에(https://sir.kr/g3_qa/2521) @리자 님이 건의를 받고 변경한 것이 지금까지 유지되고 있는 것 같습니다.
어떻게 보면 간결하고 의미가 정확한 테이블명이 맞다고 생각되지만 seo 차원에서 의미를 명확하게 보여주는 주소줄이 더 좋지 않을까 싶네요.
"그누보드의구조"라는 게시판의 bo_table명이 "structure_of_the_gnuboard"이라고 가정하면
현재의 구조에서는 주소창에
domain.com/structure_of_the_gnu/게시글-제목/
게시판 제목이 잘려 나오게 되겠지요.
만약 varchar(255)처럼 제약이 있거나 하지 않는다면 - 요즘은 이 제약도 없는 듯 하지만요 - 더 길게 변경하면 어떨까 싶네요.
냑 회원님들의 의견이 궁금합니다.
추천
1
1
댓글 14개
목적을 달성할 수 있느냐..없느냐인데
저는 프로그램 하는 사랍은 아닙니다만
효율성으로 봤을때...
20 이면 충분하지 않을까 생각합니다.
너무 길면 기억하기도 어렵고요.
저는 프로그램 하는 사랍은 아닙니다만
효율성으로 봤을때...
20 이면 충분하지 않을까 생각합니다.
너무 길면 기억하기도 어렵고요.
@해피아이
맞습니다. gnuboard_config 라고 하면 더 명확하지만 g5_config 라고 했을 때에는 효율성을 더 중요하게 여기는 부분이 크게 차지한다고 생각합니다.
하지만 게시글의 제목 처럼 게시판명도 그 의미를 정확하게 알게 해주는 것에 의미를 부여해야 하지 않을까 싶어서 생각해보았습니다.
저도 게시판명을 길게 만드는 경우가 거의 없지만 감춰진 테이블명과 다르게 게시판명은 나만 보고 이해하면 되는게 아니라는 생각이 들어서요.
맞습니다. gnuboard_config 라고 하면 더 명확하지만 g5_config 라고 했을 때에는 효율성을 더 중요하게 여기는 부분이 크게 차지한다고 생각합니다.
하지만 게시글의 제목 처럼 게시판명도 그 의미를 정확하게 알게 해주는 것에 의미를 부여해야 하지 않을까 싶어서 생각해보았습니다.
저도 게시판명을 길게 만드는 경우가 거의 없지만 감춰진 테이블명과 다르게 게시판명은 나만 보고 이해하면 되는게 아니라는 생각이 들어서요.
그냥 필요하신분만 255로 바꾸어 쓰면 될듯 합니다.
@love1
이미 사이트 몇개는 변경해서 사용하고 있습니다. 변경하는게 큰일은 아닌데 어떤 것이 더 효율적이거나 생산적인지 의견이 궁금해서요.
세상 대부분의 일이 그러하겠지만 필요한만큼 내맘대로 바꿔서 살면 편하겠지요. 하지만 원칙이라는게 있으니 세월의 흐름에 따라 그 원칙을 변경하는게 맞나 아닌가를 알고 싶었습니다.
이미 사이트 몇개는 변경해서 사용하고 있습니다. 변경하는게 큰일은 아닌데 어떤 것이 더 효율적이거나 생산적인지 의견이 궁금해서요.
세상 대부분의 일이 그러하겠지만 필요한만큼 내맘대로 바꿔서 살면 편하겠지요. 하지만 원칙이라는게 있으니 세월의 흐름에 따라 그 원칙을 변경하는게 맞나 아닌가를 알고 싶었습니다.
프로그램 초창기에는 메모리가 비싸서, 디비 구조를 꼭 필요한 만큼만 사용했습니다. 이 것을 얼마나 잘 만드냐가 큰 일이었죠. 8비트 바이트 하나도 쪼개서 저장했던 기억이...
@마젠토
맞습니다. 현재도 여분필드를 쪼개서 사용하는 경우가 많이 있지요. 지금은 메모리 뿐만 아니라 호출, 연산 등이 비교할 수 없을 정도로 변했는데 어떤게 맞을런가 모르겠습니다.
맞습니다. 현재도 여분필드를 쪼개서 사용하는 경우가 많이 있지요. 지금은 메모리 뿐만 아니라 호출, 연산 등이 비교할 수 없을 정도로 변했는데 어떤게 맞을런가 모르겠습니다.
어느측면으로 보느냐에 따라 다른 판단을 할 수 있는 부분인데
마케팅 측면에선 롱테일키워드의 장점이 있으니 길게 하는게 맞습니다.
마케팅 측면에선 롱테일키워드의 장점이 있으니 길게 하는게 맞습니다.
@반딧불1 마케팅도 마케팅이지만 canonical 값이나 실제 검색엔진에 노출되는 주소값에도 보기 좋지 않을까 싶었습니다.
Mysql에서 테이블명을 200문자 처럼 무작정 길게 만들 수 없는 걸로 아는데요/ 64문자던가
@균이
네 무작정 길게는 안되지요. 아직까지 영문 8글자로만 제한하는 경우도 많이 보았습니다.
https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html 을 참고하면 64글자로 제한하는 것 같습니다.
네 무작정 길게는 안되지요. 아직까지 영문 8글자로만 제한하는 경우도 많이 보았습니다.
https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html 을 참고하면 64글자로 제한하는 것 같습니다.
제작자님
워드프레스 예전에 사용많이 한 이유가 SEO 좋다는 것이었는데 이런 기능도 포함이 됩니다. 메뉴명이 URL에 들어 갈 수 있도록 기능을 추가하는것을 고려해 보시면 좋을것 같습니다.
워드프레스 예전에 사용많이 한 이유가 SEO 좋다는 것이었는데 이런 기능도 포함이 됩니다. 메뉴명이 URL에 들어 갈 수 있도록 기능을 추가하는것을 고려해 보시면 좋을것 같습니다.
@반딧불1
워프와 G5&YC5는 구조상 다르기 때문에 테이블 하나에 게시글을 넣는 구조와 게시판 별로 테이블을 따로 만드는 구조와 비교할 수 없을 것 감사합니다. 말씀하신 기능은 현재의 짧은글로 대체되지 않나 싶네요. 다만 그 네이밍을 정확하게 하는 것이 필요해서 이런 제안을 해보았습니다.
워프와 G5&YC5는 구조상 다르기 때문에 테이블 하나에 게시글을 넣는 구조와 게시판 별로 테이블을 따로 만드는 구조와 비교할 수 없을 것 감사합니다. 말씀하신 기능은 현재의 짧은글로 대체되지 않나 싶네요. 다만 그 네이밍을 정확하게 하는 것이 필요해서 이런 제안을 해보았습니다.
ceo를 고려하신다면
bo_table로 출력되게로 하는 것보다 bo_subject로 출력되게 해달라고 요청하시는게 좋을 것 같네요.
bo_table로 출력되게로 하는 것보다 bo_subject로 출력되게 해달라고 요청하시는게 좋을 것 같네요.
@잉끼s
bo_subject면 참 좋겠네요.
bo_subject는 htaccess도 그렇고 전반적인 구조를 많이 만져야해서 가장 쉬운 방법만 생각해보았습니다.
5에서 안된다면 6에서는 조금 더 유저 친화적으로 변경되면 좋겠네요.
bo_subject면 참 좋겠네요.
bo_subject는 htaccess도 그렇고 전반적인 구조를 많이 만져야해서 가장 쉬운 방법만 생각해보았습니다.
5에서 안된다면 6에서는 조금 더 유저 친화적으로 변경되면 좋겠네요.
