갤러리 게시판의 테이블 구조에 대한 고민 정보
기타 갤러리 게시판의 테이블 구조에 대한 고민본문
그누4가 이미 완성단계에 접어들었으니, 괜한 딴지가 될까 두렵습니다만
그래도 제 나름대로는 한번쯤 고민해볼 문제인 것 같아서 글 올립니다.
위인들은 위인전이며 각종 기록이 남겠지만
평범한 사람들은 사진으로 그 역사가 기록됩니다.
그래서 우리가 추억을 회상하곤 할때면 보통 사진앨범을 뒤적이곤 하지요.
정보화, 디지탈 시대에 살고있는 현대인들에게는 갤러리게시판이 곧
사진앨범이나 마찬가지이다고 봅니다.
그런데 사진의 경우 한번 인화해놓으면 몇십년간 안정적인 보관이 가능한데 반해,
갤러리게시판에 올려진 디지탈 사진의 경우에는 여러가지 위험에 노출되어 있습니다.
하드가 고장난다던지, 웹호스팅받는 계정업체에 문제가 생기면...
이는 철저한 백업을 통해 대비하는 수밖에 없을 겁니다.
또 하나의 문제는... 사진앨범은 사진을 붙이고 아래에 몇자 적으면 그 형태가 그대로
보존이 되는데, 디지탈갤러리의 경우, 지금 통용되는 형태가 30년 후에도 사용가능할런지
아무도 확신이 불가능하다는 것입니다. 제 경우에도 테크에서 제로, 제로에서 그누3,
그누3 에서 그누4 등으로 몇년마다 한번씩 분명히 바뀝니다.
예를 들어, 그누3 에서 그누4 로 게시판을 컨버팅할 경우, 갤러리의 형태도 그대로
따라와야 하는데, 각자가 사용하는 스킨이 다양하고 그 모든 스킨들이 다 게시판
업그레이드에 맞춰서 업그레이드되는 것은 아니기 때문에,
일반사용자의 경우, 업그레이드를 따라오기가 힘든 형편입니다.
우선은 그누3를 써도 괜찮겠지만 10년 후면 서버환경도 바뀔테고 그때의 서버에서는
그누10 은 돌아가도 그누3는 안돌아가는 상황이 발생할 가능성이 크다고 생각합니다.
그러면 결국에는 ...
이러한 관점에서 보면, 갤러리 게시판의 경우 어느정도의 표준화가 필요할 것 같습니다.
아울러, 데이터 처리에 있어서도 컨버팅이 쉽도록 디비 구조화에 신경을 써야 할 겁니다.
그누3 에서 그누4로 넘어오면서 관리자 설정에서 파일설명을 붙일 수 있는 기능이 생겼고,
이 기능 덕분에 갤러리의 각각의 사진에 설명을 붙이기가 엄청 간편해졌습니다.
하지만, 이 설명이 게시판 자체 테이블이 아닌 파일 전용 테이블을 사용함으로서
컨버팅시키기에는 더 불편해진 것도 사실입니다.
별거 아닌 문제가지고 심각하게 이야기하는 것인지도 모르겠지만...
홈페이지의 엔진이라고 할 수 있는 게시판의 패러다임이
이미 XX 보드에서 그누보드로 넘어와있는 현실에서,
그누보드 이용자로서 한번쯤 고민해봐야 할 것같다는 생각이 들었습니다.
긴 글 읽어주셔서 감사합니다.
그래도 제 나름대로는 한번쯤 고민해볼 문제인 것 같아서 글 올립니다.
위인들은 위인전이며 각종 기록이 남겠지만
평범한 사람들은 사진으로 그 역사가 기록됩니다.
그래서 우리가 추억을 회상하곤 할때면 보통 사진앨범을 뒤적이곤 하지요.
정보화, 디지탈 시대에 살고있는 현대인들에게는 갤러리게시판이 곧
사진앨범이나 마찬가지이다고 봅니다.
그런데 사진의 경우 한번 인화해놓으면 몇십년간 안정적인 보관이 가능한데 반해,
갤러리게시판에 올려진 디지탈 사진의 경우에는 여러가지 위험에 노출되어 있습니다.
하드가 고장난다던지, 웹호스팅받는 계정업체에 문제가 생기면...
이는 철저한 백업을 통해 대비하는 수밖에 없을 겁니다.
또 하나의 문제는... 사진앨범은 사진을 붙이고 아래에 몇자 적으면 그 형태가 그대로
보존이 되는데, 디지탈갤러리의 경우, 지금 통용되는 형태가 30년 후에도 사용가능할런지
아무도 확신이 불가능하다는 것입니다. 제 경우에도 테크에서 제로, 제로에서 그누3,
그누3 에서 그누4 등으로 몇년마다 한번씩 분명히 바뀝니다.
예를 들어, 그누3 에서 그누4 로 게시판을 컨버팅할 경우, 갤러리의 형태도 그대로
따라와야 하는데, 각자가 사용하는 스킨이 다양하고 그 모든 스킨들이 다 게시판
업그레이드에 맞춰서 업그레이드되는 것은 아니기 때문에,
일반사용자의 경우, 업그레이드를 따라오기가 힘든 형편입니다.
우선은 그누3를 써도 괜찮겠지만 10년 후면 서버환경도 바뀔테고 그때의 서버에서는
그누10 은 돌아가도 그누3는 안돌아가는 상황이 발생할 가능성이 크다고 생각합니다.
그러면 결국에는 ...
이러한 관점에서 보면, 갤러리 게시판의 경우 어느정도의 표준화가 필요할 것 같습니다.
아울러, 데이터 처리에 있어서도 컨버팅이 쉽도록 디비 구조화에 신경을 써야 할 겁니다.
그누3 에서 그누4로 넘어오면서 관리자 설정에서 파일설명을 붙일 수 있는 기능이 생겼고,
이 기능 덕분에 갤러리의 각각의 사진에 설명을 붙이기가 엄청 간편해졌습니다.
하지만, 이 설명이 게시판 자체 테이블이 아닌 파일 전용 테이블을 사용함으로서
컨버팅시키기에는 더 불편해진 것도 사실입니다.
별거 아닌 문제가지고 심각하게 이야기하는 것인지도 모르겠지만...
홈페이지의 엔진이라고 할 수 있는 게시판의 패러다임이
이미 XX 보드에서 그누보드로 넘어와있는 현실에서,
그누보드 이용자로서 한번쯤 고민해봐야 할 것같다는 생각이 들었습니다.
긴 글 읽어주셔서 감사합니다.
추천
0
0
댓글 5개
댓글을 통해 많은 것을 배웁니다.
사용자의 압박이야 말로 운영자의 즐거움 !
'너무 앞서나가지 말자' 제게도 따끔한 교훈이네요.
한우물만 파자 ! 수업료만 내고 딴데 가면 안되겠죠.
감사합니다.
사용자의 압박이야 말로 운영자의 즐거움 !
'너무 앞서나가지 말자' 제게도 따끔한 교훈이네요.
한우물만 파자 ! 수업료만 내고 딴데 가면 안되겠죠.
감사합니다.
훗~~~답글들이 무지 공감이 가는 이야기들 입니다....^^;;
난 늦깍이로 98년 컴퓨터 과학과를 입문했는데,,,,
이놈의 c** 이랑 파스칼, 그기다, 자바 등등.... 혼자서 독학 비스무리 하게 공부 하여야 했는데,,,
나중엔 홈페이지 만든다고, 플래쉬랑,포토샵,일러스트 등등의 폼내는것에만 눈이 돌아가구,,,,
숱한 버젼업그레이드 때문에그당시 사놓은 책들이 몇백만원은 들어 간것 같아요,,,,,
사고 나서 읽고 공부하고 있어면 업된책이 나오구~~~~ㅜㅜ
결론은 지금 이모양 입니다....ㅋㅋㅋ
아무것도 잘하는게 없다는~~~쩝~~~~뭔가를 이루고 싶어면, 한우물에 충실해야 할듯~~~^^;;
답글 읽다보니 공감이 가서 나두 넋두리 한마디 하였네요~~~ㅜㅜ
난 늦깍이로 98년 컴퓨터 과학과를 입문했는데,,,,
이놈의 c** 이랑 파스칼, 그기다, 자바 등등.... 혼자서 독학 비스무리 하게 공부 하여야 했는데,,,
나중엔 홈페이지 만든다고, 플래쉬랑,포토샵,일러스트 등등의 폼내는것에만 눈이 돌아가구,,,,
숱한 버젼업그레이드 때문에그당시 사놓은 책들이 몇백만원은 들어 간것 같아요,,,,,
사고 나서 읽고 공부하고 있어면 업된책이 나오구~~~~ㅜㅜ
결론은 지금 이모양 입니다....ㅋㅋㅋ
아무것도 잘하는게 없다는~~~쩝~~~~뭔가를 이루고 싶어면, 한우물에 충실해야 할듯~~~^^;;
답글 읽다보니 공감이 가서 나두 넋두리 한마디 하였네요~~~ㅜㅜ
잘 읽었습니다.
대략..무슨 말씀인지는 알겠습니다.
제 생각을 써 볼께요...
저는 좀 무계획으로 가려합니다.
지포와는 상관 없는 내용이지만 ...이런 생각이 있답니다.
.
.
fortran cobol 죽도록 했군요.
그런 와중에 앞으로는 C 를 하지 않으면...도태된다...또 했습니다.
혹자는 책에서 앞으로는 File System 이 없어진다...했습니다.
그러다가 갑자기 파일은 존재하고
하드 용량이 늘어나고 씨퓨 클럭이 높아지면서 GUI 로 흘러버렸습니다.
비쥬얼 스튜디오로 통합이 되버리고...ㅠㅠ
좀 하다보니 이젠 COM+ ATIVEX...정말 돌아 버릴 지경이었습니다.
인생을 죠진...;;;
결과는 너무 경직된 "카더라" 학문을 믿었기 때문입니다.
이젠 C는 아무리 급해도 돌아보 질 않습니다.
이 상황에서는 그냥..물흐르듯 살아가야..될 듯 합니다.
SQL 에서 DB는 디렉토리...
테이블은 3가지...구조파일.인덱스.데이타라고 단순하게...생각합니다.
저는 요즘 백업의 개념이..무엇이 백업인지..잘 모릅니다.
죽도록 늘어나 봐야...
CD 1장의 용량도 않되는...
그래서 DB는 무조건 CD로 구워버립니다.
데이타만 통째로...slave 에 저장 시켜버립니다.
dump 하고 use \. 해버리는 수준으로 갑니다.
하드가 30메가 40메가 시절에 대형 호스트 용량이 4기가 였군요.
이때의 DB 설계와 지금의 설계는...
이때의 DB의 효율성과
현재의 사용자에게 부담을 주지 않는 효율성의 설계....??
지금의 심정은 그렇습니다.
앞으로 하드웨어가 어케 발전 할 지 모르는 상황에서 효율성에 대한 정석은 없는 것 같다는...;;
최대한 버라이어티하게..화려하게..거기에 기술적으로 발전하면서...
느리면 기계바꾸라는...
내 프로그램 쓰려면 기계 바꾸라는..이렇게 해야 할듯 합니다.
그리고
얼마전 좀 비싼 고화질 PDP 보니깐...
이젠...일반 모니터도 얼마 남지 않았다..듀얼 모니터가 웬말...
이미 TV와 컴퓨터인터넷이 하나로 활성화가 되버렸다는 생각과
모바일 하나면 만능이다 라는 관점에서
화상관련해서 하루 빨리 자바를 잡아야 겠다는 생각이 듭니다.
또 예전에는 프로그램어 디자이너..기획..액션..나뉘었는데...
완전히 무의미해진...
다 알아야 할 듯 합니다.
모르면 말이 안통하는 통합적인 개발환경에서 유기적으로
빨리빨리 뭔가를 만들어 가려면 다방면으로 공부 해야 할 것 같습니다.
예로 어떤 이슈가 있으면
네이버는 1시간 만에...플레쉬로 만들어 냅니다. 잠도 안자는가 싶어요...ㅋㅋ
여기에 기획,디자인,프로그램...늦어서는 안될 듯 합니다.
토탈학습과...버라이어티...하게 나갈 필요가 있어 보입니다.
계속 기계와 미디어는 발전하고 이미 발전되어 있는 느낌입니다.
엄살 떨면서...어려웠다는 둥..열이 올라간다는 둥...
당시 셀러론 266 쓰면서...450으로 오버했던 사람이 썻던
그 환상의 리뷰가...
지금은 아무것도 아니지 않습니까? ...5년도 않되었다는..;;
우리는 효율에 대해서 기죽지 말고
암튼...필요한 레코드 늘리고..닉도 한 10개쯤 만들고...
얼마전에 테이블 만들때 freeboard notics ...만들었는데..
요즘...배열로 만들어 for 로 돌려버립니다.
100개씩 만들어 버리고 있습니다.
3000 개까지는 잘 돌아갑니다.
테이블 명이 B_0001 B_0002 이렇게...0001 부분만 증가를 하고 있습니다.
셀렉트 카테고리를 주려고 또 다른 테이블을 만드느니..
B_0100 부터 B_0199 까지는 1개의 카테고리로 주면
만약 200 보다 적으면...이케한다..저케한다가 쉬워서 입니다.
그러고 보면 mysql 공짜지만 아주 강해진 느낌입니다.
dos 시절 file 이 같은 디렉토리에 2000개면 인식 불이었습니다.
한 테이블에 num 이 800만건 까지 안정성이 있다는 소리를 들었습니다.
그렇게 많은 리플들도 잘 소화 ...
정리하자면
1.사용자의 시스템 압박은 운영자의 즐거움.
2.목수도 엄청나게 화려한 집을 가지고 있어야 견적이라도 들어온다.
3.법적인 한도 내에서 최대한 야하게...최대한 불나방 처럼 번뜩이자.
4.앞으로 명함엔 다 필요없고 pe.kr 싸이트 명 하나만 넣을 작정입니다.
제 이름이 필요한 사람은 이미 인터넷 하고 있을 것이니까요..
.
.
감싸합니다. 리딩해 주셔서---ㅋ
만약에...걸리는 부분이 있으신 분은..
걍...pass 부탁드립니다요~~`^^;
대략..무슨 말씀인지는 알겠습니다.
제 생각을 써 볼께요...
저는 좀 무계획으로 가려합니다.
지포와는 상관 없는 내용이지만 ...이런 생각이 있답니다.
.
.
fortran cobol 죽도록 했군요.
그런 와중에 앞으로는 C 를 하지 않으면...도태된다...또 했습니다.
혹자는 책에서 앞으로는 File System 이 없어진다...했습니다.
그러다가 갑자기 파일은 존재하고
하드 용량이 늘어나고 씨퓨 클럭이 높아지면서 GUI 로 흘러버렸습니다.
비쥬얼 스튜디오로 통합이 되버리고...ㅠㅠ
좀 하다보니 이젠 COM+ ATIVEX...정말 돌아 버릴 지경이었습니다.
인생을 죠진...;;;
결과는 너무 경직된 "카더라" 학문을 믿었기 때문입니다.
이젠 C는 아무리 급해도 돌아보 질 않습니다.
이 상황에서는 그냥..물흐르듯 살아가야..될 듯 합니다.
SQL 에서 DB는 디렉토리...
테이블은 3가지...구조파일.인덱스.데이타라고 단순하게...생각합니다.
저는 요즘 백업의 개념이..무엇이 백업인지..잘 모릅니다.
죽도록 늘어나 봐야...
CD 1장의 용량도 않되는...
그래서 DB는 무조건 CD로 구워버립니다.
데이타만 통째로...slave 에 저장 시켜버립니다.
dump 하고 use \. 해버리는 수준으로 갑니다.
하드가 30메가 40메가 시절에 대형 호스트 용량이 4기가 였군요.
이때의 DB 설계와 지금의 설계는...
이때의 DB의 효율성과
현재의 사용자에게 부담을 주지 않는 효율성의 설계....??
지금의 심정은 그렇습니다.
앞으로 하드웨어가 어케 발전 할 지 모르는 상황에서 효율성에 대한 정석은 없는 것 같다는...;;
최대한 버라이어티하게..화려하게..거기에 기술적으로 발전하면서...
느리면 기계바꾸라는...
내 프로그램 쓰려면 기계 바꾸라는..이렇게 해야 할듯 합니다.
그리고
얼마전 좀 비싼 고화질 PDP 보니깐...
이젠...일반 모니터도 얼마 남지 않았다..듀얼 모니터가 웬말...
이미 TV와 컴퓨터인터넷이 하나로 활성화가 되버렸다는 생각과
모바일 하나면 만능이다 라는 관점에서
화상관련해서 하루 빨리 자바를 잡아야 겠다는 생각이 듭니다.
또 예전에는 프로그램어 디자이너..기획..액션..나뉘었는데...
완전히 무의미해진...
다 알아야 할 듯 합니다.
모르면 말이 안통하는 통합적인 개발환경에서 유기적으로
빨리빨리 뭔가를 만들어 가려면 다방면으로 공부 해야 할 것 같습니다.
예로 어떤 이슈가 있으면
네이버는 1시간 만에...플레쉬로 만들어 냅니다. 잠도 안자는가 싶어요...ㅋㅋ
여기에 기획,디자인,프로그램...늦어서는 안될 듯 합니다.
토탈학습과...버라이어티...하게 나갈 필요가 있어 보입니다.
계속 기계와 미디어는 발전하고 이미 발전되어 있는 느낌입니다.
엄살 떨면서...어려웠다는 둥..열이 올라간다는 둥...
당시 셀러론 266 쓰면서...450으로 오버했던 사람이 썻던
그 환상의 리뷰가...
지금은 아무것도 아니지 않습니까? ...5년도 않되었다는..;;
우리는 효율에 대해서 기죽지 말고
암튼...필요한 레코드 늘리고..닉도 한 10개쯤 만들고...
얼마전에 테이블 만들때 freeboard notics ...만들었는데..
요즘...배열로 만들어 for 로 돌려버립니다.
100개씩 만들어 버리고 있습니다.
3000 개까지는 잘 돌아갑니다.
테이블 명이 B_0001 B_0002 이렇게...0001 부분만 증가를 하고 있습니다.
셀렉트 카테고리를 주려고 또 다른 테이블을 만드느니..
B_0100 부터 B_0199 까지는 1개의 카테고리로 주면
만약 200 보다 적으면...이케한다..저케한다가 쉬워서 입니다.
그러고 보면 mysql 공짜지만 아주 강해진 느낌입니다.
dos 시절 file 이 같은 디렉토리에 2000개면 인식 불이었습니다.
한 테이블에 num 이 800만건 까지 안정성이 있다는 소리를 들었습니다.
그렇게 많은 리플들도 잘 소화 ...
정리하자면
1.사용자의 시스템 압박은 운영자의 즐거움.
2.목수도 엄청나게 화려한 집을 가지고 있어야 견적이라도 들어온다.
3.법적인 한도 내에서 최대한 야하게...최대한 불나방 처럼 번뜩이자.
4.앞으로 명함엔 다 필요없고 pe.kr 싸이트 명 하나만 넣을 작정입니다.
제 이름이 필요한 사람은 이미 인터넷 하고 있을 것이니까요..
.
.
감싸합니다. 리딩해 주셔서---ㅋ
만약에...걸리는 부분이 있으신 분은..
걍...pass 부탁드립니다요~~`^^;
주제와는 상관없는 오달수님에 대한 답글입니다.
저도 코볼을 죽어라 만진 사람중에 하나입니다.
그런데 그당시는 C 모르면 안된다면서 여러곳에서 굉장히 강조를 하더군요. 전 청개구리 성질이 있어 파스칼을 공부했더랬죠. ^^
C 를 좀 배우려니까 비쥬얼 뭐다 뭐다 하면서 머리 아플정도로 많이 나오더군요.
개발자는 일하지 않을때까지 공부하는거라면서... 암튼 이것저것 많이는 배웠는데 나중에 보니까 아는게 하나도 없더라구요.
Y2K 어쩌고 하면서 내일이면 곧 망할것 처럼 연신 매스컴에서 떠들어 대던 그당시 코볼 개발자가 C 개발자보다 수배 이상 급여를 받고 수년전까지만 하더라도 코볼 개발자 수급이 제대로 되지 않아 급여가 상당히 높았던 기억이 있습니다. 아~ 이것저것 배우지 말고 코볼만 잡았으면 좋았을걸 하는 생각이 간절하더군요.
지금도 잊지 못하는 네개의 디비젼을 속으로 삼키며 마음속 깊이 간직하고 있는 저만의 신념은 '너무 앞서가지 말자' 입니다.
저도 코볼을 죽어라 만진 사람중에 하나입니다.
그런데 그당시는 C 모르면 안된다면서 여러곳에서 굉장히 강조를 하더군요. 전 청개구리 성질이 있어 파스칼을 공부했더랬죠. ^^
C 를 좀 배우려니까 비쥬얼 뭐다 뭐다 하면서 머리 아플정도로 많이 나오더군요.
개발자는 일하지 않을때까지 공부하는거라면서... 암튼 이것저것 많이는 배웠는데 나중에 보니까 아는게 하나도 없더라구요.
Y2K 어쩌고 하면서 내일이면 곧 망할것 처럼 연신 매스컴에서 떠들어 대던 그당시 코볼 개발자가 C 개발자보다 수배 이상 급여를 받고 수년전까지만 하더라도 코볼 개발자 수급이 제대로 되지 않아 급여가 상당히 높았던 기억이 있습니다. 아~ 이것저것 배우지 말고 코볼만 잡았으면 좋았을걸 하는 생각이 간절하더군요.
지금도 잊지 못하는 네개의 디비젼을 속으로 삼키며 마음속 깊이 간직하고 있는 저만의 신념은 '너무 앞서가지 말자' 입니다.
오~~ 영자님...코볼도 하셨군요...^^;
저두 Y2K...잡아 놓으니깐..."얼마에요"...가 나와서리...
99 년 1년은 헛고생 했답니다...
여담이지만 당시 Y2K 에 대해서 글을 썻는데 이종환 최유라에 나왔습니다.
삼정인버터스텐드 하나 받고 한턱내라고 해서 술값이..
좀 들어갔었습니다...ㅋㅋ
모든 분들...기필코 기어이...꼭...승리 하시길 바랍니다.^^;;;
저두 Y2K...잡아 놓으니깐..."얼마에요"...가 나와서리...
99 년 1년은 헛고생 했답니다...
여담이지만 당시 Y2K 에 대해서 글을 썻는데 이종환 최유라에 나왔습니다.
삼정인버터스텐드 하나 받고 한턱내라고 해서 술값이..
좀 들어갔었습니다...ㅋㅋ
모든 분들...기필코 기어이...꼭...승리 하시길 바랍니다.^^;;;
