아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
텍스트큐브 2.0 백엔드 설계를 하다보니 MySQL 3.x가 역시나 걸리네요.
제가 대충 알기로는 일단 유니코드 쪽 지원이 안 된다는 점하고 foreign key와 고급 join/subquery 같은 게 안 된다는 점 정도인데 그 외에 어떤 차이점이 있는지 혹시 다른 분들이 알려주시면 좋겠습니다.
생각 같아서는 PHP4도 확 버리고 PHP5 전용으로 하고 싶지만(.....이렇게 하면 코드를 훨씬 깔끔하게 할 수 있습니다) 이건 좀 무리겠지요?;;;
DB 모듈을 잘만 짜면 MySQL 3.x 지원도 어찌 가능할 것 같긴 한데 현실적으로 해야 되나 의문입니다. 호스팅들 중에 아직도 MySQL 3.x 쓰는 곳이 있나요?;
daybreaker (2008-06-09 18:59:44)에 의해 마지막으로 수정
전 이젠 버려도 괜찮다고 생각합니다. 2년이면 마이 지원했죠...
곧 MySQL 6이 나오죠? ...
1. mysql 3.X는 제로보드 4 때문에 생긴 부분입니다. 머 이젠 버려도..
네, 그럼 일단 백엔드 설계에서 mysql 3.x 지원은 없는 걸로 하겠습니다.
mysql 4.x에서 innodb가 아닌 경우는 어찌되는지 좀더 알아봐야겠군요.
php4는 어쩔까요? (.....) php6 전용 고고싱? =3=3
daybreaker (2008-06-09 20:25:19)에 의해 마지막으로 수정
예전에 한번 PHP5 이상 지원 웹 어플 때문에 PHP5 를 지원하는 국내 호스팅을 찾아봤었는데, 거의 다가 PHP4 만을 지원하고 있더군요... 이 부분은 다소 고려를 해봐야 되지 않을까 싶습니다;;
예전에 한번 PHP5 이상 지원 웹 어플 때문에 PHP5 를 지원하는 국내 호스팅을 찾아봤었는데, 거의 다가 PHP4 만을 지원하고 있더군요... 이 부분은 다소 고려를 해봐야 되지 않을까 싶습니다;;
흠.. 지금 찾아보니 php5의 magic method들을 php4에서도 쓸 있더군요. 그것도 텍스트큐브의 설치 조건인 4.3.0 이상에서요.
성능은 좀 떨어집니다만 일단 php4에서도 돌아는 가게 깔끔한 구현이 가능할 것 같네요.
CakePHP도 이미 같은 삽질을 해놨고.
생각 같아선 php5 강제하고 싶습니다....ㅠㅠ
php5를 쓰게 되면 캐시와 DB 백엔드를 모두 abstract class로 정의해서 필요에 따라 자기가 직접 구현해서 쓸 수 있게 모듈화하는 것이 굉장히 용이해집니다만... 하아 -_-;
ps. 홍민희님이 만드신 phunctional을 도입해볼까요? =3=3
daybreaker (2008-06-10 00:28:21)에 의해 마지막으로 수정
3.X는 버리는 문제와는 별개로 DB의 경우 mysql의 경우만을 고려하는 것은 지양해야 합니다. 이 점도 같이 고려를 
3.X는 버리는 문제와는 별개로 DB의 경우 mysql의 경우만을 고려하는 것은 지양해야 합니다. 이 점도 같이 고려를
넵, 물론입니다.
어차피, sqlite가 foreign key를 지원하지 않고 trigger로만 제약을 걸 수 있다든가 이런 식이라서 결국 독립성을 보장해야 하긴 합니다.
php5를 쓰게 되면 캐시와 DB 백엔드를 모두 abstract class로 정의해서 필요에 따라 자기가 직접 구현해서 쓸 수 있게 모듈화하는 것이 굉장히 용이해집니다만... 하아 -_-;
ps. 홍민희님이 만드신 phunctional을 도입해볼까요? =3=3
이거 php4.3에서도 돌아갈까요? 람다를 구현하는걸 생각해보면 아무리해도 php4 대에서는 답이 안나오는데...
daybreaker 작성:php5를 쓰게 되면 캐시와 DB 백엔드를 모두 abstract class로 정의해서 필요에 따라 자기가 직접 구현해서 쓸 수 있게 모듈화하는 것이 굉장히 용이해집니다만... 하아 -_-;
ps. 홍민희님이 만드신 phunctional을 도입해볼까요? =3=3
이거 php4.3에서도 돌아갈까요? 람다를 구현하는걸 생각해보면 아무리해도 php4 대에서는 답이 안나오는데...
아쉽게도 안 돌아갑니다...
토끼군이 hack으로 lambda를 만든 방법이, static 변수를 사용하는 함수를 create_function으로 만들어내는 것이었습니다만 한두 개라면 모를까 본격적으로 쓰기에는 성능상 엄청난 문제가 생긴다고 합니다.
daybreaker 작성:inureyes 작성:이거 php4.3에서도 돌아갈까요? 람다를 구현하는걸 생각해보면 아무리해도 php4 대에서는 답이 안나오는데...
아쉽게도 안 돌아갑니다...
토끼군이 hack으로 lambda를 만든 방법이, static 변수를 사용하는 함수를 create_function으로 만들어내는 것이었습니다만 한두 개라면 모를까 본격적으로 쓰기에는 성능상 엄청난 문제가 생긴다고 합니다.phunctional에서 람다를 만드는 방법이 두 가지인데, 하나는 def()와 fed()가 나타나는 파일의 경로와 줄 수를 debug_backtrace를 통해 알아내고, 이 사이에 있는 내용을 직접 "파일을 읽어서"(!) 가져오는 방식입니다. 그리고 나머지 하나는 create_function을 단순히 매핑하는 방식입니다. 두 가지 다 성능상에 문제가 있어서 도입하기는 약간^^ 어려울 것 같습니다~
소스코드를 읽어보니 그렇네요. 흐음;;
정규님이 lambda를 원하시는 이유가 스킨 처리 루틴을 lazy evaluation으로 바꾸기 위해서였는데, 좋은 방법 없을까요? (php 버리고 python으로 가자 이런 거 빼구..ㅠㅠ)
사실 CakePHP를 보면서, 또 직접 구현하려고 생각하면서 dictionary 형태의 자료를 주고받으려면 array('xxx' => 'yyy')를 항상 전부 다 적어줘야 한다는 점부터 벌써 근질근질합니다...orz 아, 너무 python에 물들었나봐요..ㅠㅠ
daybreaker (2008-06-10 06:45:26)에 의해 마지막으로 수정
사실 CakePHP를 보면서, 또 직접 구현하려고 생각하면서 dictionary 형태의 자료를 주고받으려면 array('xxx' => 'yyy')를 항상 전부 다 적어줘야 한다는 점부터 벌써 근질근질합니다...orz 아, 너무 python에 물들었나봐요..ㅠㅠ
compact() 함수를 쓰면 조금(?)은 중복이 줄어듭니다. (리퍼러에 못보던 URL이 찍혀있길래 와보니 TNF 포럼이었군요~)
이제 슬슬 스펙을 결정 지을까요?
1. MySQL 3.23 은 버린다. ( < MySQL 4.1 은 안녕안녕?)
2. PHP 4.3은?
1번은 만드는게 취미인 사람들 투성이라 그런지 확정 분위기이고, 2번은 어떻게 할까요?
혹시 1번에 대해서도 반대하시는 분 있으시면 언제든지 의견을~
확정되는대로 미리 공지하겠습니다. 2.0 나가기 한참 전에 스펙을 공지해 두는 것이 호스팅 연장을 예정중인 분들께 혼란이 덜하게 되니까요.^^
으음... php.net 에서는 5.2 이상으로 업글을 권장하는군요.
말 잘 듣고 5.2 이상으로 가면... 어떻게 되려나요?
흠 현재 사용하고 있는 php버전을 빠르게 수집할 방법 없을까요...........흠-_-
문제는.. 기존 많은 4대 PHP코드가 5를 만나면 오동작할 가능성이 매우 높습니다.
PHP는 버전별로 전혀 다른 언어! 심지어 ini따라서도 ;;;
현재 결정되는 버전이 향후 2~3년간은 계속 따라다니게 될게 분명하기 때문에 PHP5, MySQL4.1 이상으로 가는 것이 좋을 것 같습니다.(PHP4는 지원도 중단됐고..)
예전 태터툴즈가 그랬듯이 텍스트큐브2.0도 해당 업계를 선도(?)할 수 있는 도구가 되었으면 좋겠습니다.(대상이 현재가 아니었으면 합니다.)
2.0 배포 후 안정화 단계가 될때쯤에는 어느정도 규모가 있는 업체들은 다 따라오지 않을까 생각합니다.
그리고 주제와는 별개지만 텍스트큐브2.0은 "태터 프레임워크"를 개발하고 그걸 기반으로 제작하는게 어떨까요?
"프로젝트 태터툴즈"의 이상을 구현하기 위해 조금 더 쉽게 접근할 수 있는 틀을 제공하는 것도 Needlworks와 TNF가 해야될 일이지 않은가?라는 생각이 드는군요.
문제는.. 기존 많은 4대 PHP코드가 5를 만나면 오동작할 가능성이 매우 높습니다.
PHP는 버전별로 전혀 다른 언어! 심지어 ini따라서도 ;;;
뭐 제 서버가 5.2니까 기존 코드의 오동작의 가능성은 고려하지 않으셔도... ㅎㅎ
gendoh 작성:문제는.. 기존 많은 4대 PHP코드가 5를 만나면 오동작할 가능성이 매우 높습니다.
PHP는 버전별로 전혀 다른 언어! 심지어 ini따라서도 ;;;
만약 텍스트큐브 2.0이 지원 사항을 PHP 5로 높인다면 지금 MySQL UTF-8 서버와 EUC-KR 서버로 나누어서 상품을 제공하는 것처럼 PHP 4와 5로 서버 나누어서 호스팅 제공할지도 모르겠습니다 ㅡㅡ;;
보통 그게 제로보드 4때문에 생긴 제약이라
euc_kr/php4/mysql3.x
utf-8/php5/mysql4~5
로 나누더군요.
gofeel 작성:Creorix 작성:만약 텍스트큐브 2.0이 지원 사항을 PHP 5로 높인다면 지금 MySQL UTF-8 서버와 EUC-KR 서버로 나누어서 상품을 제공하는 것처럼 PHP 4와 5로 서버 나누어서 호스팅 제공할지도 모르겠습니다 ㅡㅡ;;
보통 그게 제로보드 4때문에 생긴 제약이라
euc_kr/php4/mysql3.x
utf-8/php5/mysql4~5로 나누더군요.
뭐 그렇다면 PHP 5로 올라가도 되지 않을까요? 어차피 텍스트큐브 쓰시는 분들은 UTF-8 DB를 선택하실테니 말입니다
네, 문제는 지금 일정대로 2.0을 발표한다면 충격흡수가 어려울 것이라는 생각이 듭니다.
php5 & mysql 4로 확정한다면, 릴리즈 일정을 길게 갈 필요성이 있어 보입니다.
+ 이러한 충격을 흡수할 보조 프로그램들이 필요하다고 생각합니다. 현재의 ttxml 백업은 플랫폼 간 교환과 일반적인 백업상황에는 적합하지만, 모든 환경이 유지되는 업그레이드용 백업에는 딱 맞다고 보기는 힘들죠.
흠 현재 사용하고 있는 php버전을 빠르게 수집할 방법 없을까요...........흠-_-
http://koreahosting.or.kr/tt/board/ttbo … tro_member
http://koreahosting.or.kr/tt/board/ttbo … ro_member1
물론 해당 한국인터넷협회 회원사는 일부겠습니다만... 한번 살펴볼까요?;
gofeel 작성:흠 현재 사용하고 있는 php버전을 빠르게 수집할 방법 없을까요...........흠-_-
http://koreahosting.or.kr/tt/board/ttbo … tro_member
http://koreahosting.or.kr/tt/board/ttbo … ro_member1물론 해당 한국인터넷협회 회원사는 일부겠습니다만... 한번 살펴볼까요?;
어차피 알아보아도 결정에 큰 영향은 미치지 않을듯 싶습니다...
릴리즈 일정을 잡되, gofeel님 말씀처럼 충격 흡수가 요구되니 2.0과 1.7 가운데의 브릿지가 필요하겠군요. 편법이기는 하지만 2.0 개발 일정 중에 1.8을 내놓고, 1.8의 다른 부분은 1.7과 동일하지만 DB 백엔드와 요구사항만 올리는 식의 접근도 버퍼식으로 필요할 것 같기는 합니다.
어떤 쪽이든, 차후 메이저 버전에 대한 요구사항은 결정지어야 할 것 같네요. 그럼 정리해서 다음의 안들이 있습니다.
1. MySQL 4.1 / PHP 4.3
2. MySQL 4.1 / PHP 5.1
3. MySQL 5 / PHP 5.1
4. MySQL 5 / PHP 5.2
이제 골라보죠. 저는... 4번? 
제x보드 5가 망하긴(?) 했지만, 국내 호스팅 환경의 MySQL 서버 버전을 바꾸는 데 한 몫 했던 것과 같이 텍스트큐브 덕에 PHP 5로 넘어가는 곳이 많이 생겼으면 좋겠습니다.
기대를 걸어봅니다.
니들웍스