아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
텍스트큐브 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이 나오죠? ...
저도 MySQL 3.x대는 버려도 될 것 같습니다 
p.s. foreign key는 어차피 4 이상에서도 storage engine을 InnoDB로 하지 않으면 안되지 않나요?
1. mysql 3.X는 제로보드 4 때문에 생긴 부분입니다. 머 이젠 버려도..
네, 그럼 일단 백엔드 설계에서 mysql 3.x 지원은 없는 걸로 하겠습니다.
mysql 4.x에서 innodb가 아닌 경우는 어찌되는지 좀더 알아봐야겠군요.
php4는 어쩔까요? (.....) php6 전용 고고싱? =3=3
daybreaker (2008-06-09 20:25:19)에 의해 마지막으로 수정
InnoDB의 경우 MyISAM과 달리
* Row-level lock (MyISAM은 table lock이지요)
* transaction, foreign key 지원 (multi-depth transaction도 지원하는지는 기억이 잘;;; )
* 파일이 tablespace 단위로 생성됨 (MyISAM은 인덱스와 데이터가 각기 다른 파일에 저장되구요)
이 정도의 기능 차이가 있습니다. 다만 호스팅에서 InnoDB를 사용하지 못하도록 MySQL 설정을 해 둘 수도 있어서 이게 좀 문제가 될 수도 있습니다 
p.s. MySQL 4 이상으로 올리셨으니 mysqli 확장이 사용 가능한 곳에서는 mysqli extension 사용을 고려해 보는 것도 좋을 것 같습니다 ^^
Creorix (2008-06-09 20:35:45)에 의해 마지막으로 수정
예전에 한번 PHP5 이상 지원 웹 어플 때문에 PHP5 를 지원하는 국내 호스팅을 찾아봤었는데, 거의 다가 PHP4 만을 지원하고 있더군요... 이 부분은 다소 고려를 해봐야 되지 않을까 싶습니다;;
사실 텍스트큐브 같은 프로그램이 최소사양을 올려야 호스팅업체들도 따라올텐데 말이죠 -_- (1.0 당시 UTF-8 DB 관련 이슈로 호스팅계(?)가 크게 바뀌었지요)
저도 마음 같아선 PHP 5로 확 올리고 싶습니다 ㅠㅠ
예전에 한번 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으로 만들어내는 것이었습니다만 한두 개라면 모를까 본격적으로 쓰기에는 성능상 엄청난 문제가 생긴다고 합니다.
inureyes 작성:daybreaker 작성:php5를 쓰게 되면 캐시와 DB 백엔드를 모두 abstract class로 정의해서 필요에 따라 자기가 직접 구현해서 쓸 수 있게 모듈화하는 것이 굉장히 용이해집니다만... 하아 -_-;
ps. 홍민희님이 만드신 phunctional을 도입해볼까요? =3=3
이거 php4.3에서도 돌아갈까요? 람다를 구현하는걸 생각해보면 아무리해도 php4 대에서는 답이 안나오는데...
아쉽게도 안 돌아갑니다...
토끼군이 hack으로 lambda를 만든 방법이, static 변수를 사용하는 함수를 create_function으로 만들어내는 것이었습니다만 한두 개라면 모를까 본격적으로 쓰기에는 성능상 엄청난 문제가 생긴다고 합니다.
phunctional에서 람다를 만드는 방법이 두 가지인데, 하나는 def()와 fed()가 나타나는 파일의 경로와 줄 수를 debug_backtrace를 통해 알아내고, 이 사이에 있는 내용을 직접 "파일을 읽어서"(!) 가져오는 방식입니다. 그리고 나머지 하나는 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 5.1 이상에서만 돈다는 소문이;;;
일단 5대로 올라가면 XML 관련 컴포넌트를 전부 DOM으로 뜯어고칠수도 있고, 현재 논의되는 ORM을 위한 PDO도 있지요
개인적으로는 올리면 아마 호스팅 업체 측에서 다들 따라오지 않을까 하는 것이 제 생각입니다만 ^^;
(PHP 버전을 올릴 때 충돌이 일어날 수 있는 유명한 프로그램이 있나요?)
으음... php.net 에서는 5.2 이상으로 업글을 권장하는군요.
말 잘 듣고 5.2 이상으로 가면... 어떻게 되려나요?
사실 5.3에 편리한 기능들(Late static binding, namespace 등)이 있어서 올라가면 편합니다만 5.3은 아직 지원하는 곳을 본 적이 없네요 ;;
5.2 정도만 되어도 개발하는 데에 수월할 것 같습니다만, 문제는 역시나 호스팅 업체들이겠지요 ^^;;
흠 현재 사용하고 있는 php버전을 빠르게 수집할 방법 없을까요...........흠-_-
문제는.. 기존 많은 4대 PHP코드가 5를 만나면 오동작할 가능성이 매우 높습니다.
PHP는 버전별로 전혀 다른 언어! 심지어 ini따라서도 ;;;
현재 결정되는 버전이 향후 2~3년간은 계속 따라다니게 될게 분명하기 때문에 PHP5, MySQL4.1 이상으로 가는 것이 좋을 것 같습니다.(PHP4는 지원도 중단됐고..)
예전 태터툴즈가 그랬듯이 텍스트큐브2.0도 해당 업계를 선도(?)할 수 있는 도구가 되었으면 좋겠습니다.(대상이 현재가 아니었으면 합니다.)
2.0 배포 후 안정화 단계가 될때쯤에는 어느정도 규모가 있는 업체들은 다 따라오지 않을까 생각합니다.
그리고 주제와는 별개지만 텍스트큐브2.0은 "태터 프레임워크"를 개발하고 그걸 기반으로 제작하는게 어떨까요?
"프로젝트 태터툴즈"의 이상을 구현하기 위해 조금 더 쉽게 접근할 수 있는 틀을 제공하는 것도 Needlworks와 TNF가 해야될 일이지 않은가?라는 생각이 드는군요.
니들웍스