리자님의 꼼꼼함..ㅎ > 자유게시판

자유게시판

리자님의 꼼꼼함..ㅎ 정보

리자님의 꼼꼼함..ㅎ

본문

초간단 cURL을 테스트중에 sir의 제작의뢰를 스크랩테스트하니 별 신통하지 않네요...

잘 방어하시는 것 같습니다.

 

phpschool은 잘 스크랩되네요..

학교는 정말 오래전 시스템을 잘 운영하는 것 같습니다. 아직도 euckr이네요... 그게 나쁜 것은 아니니까...

 

https://365ok.co.kr/webscraper/scraper.php?mode=phpschool-req

 

그런데 /bbs/write.update.php 에서 wr_content 용량을 65,536으로 제한하신 특별하신 이유라도?

mysql용량 제한도 풀고,

php 용량 제한도 풀고,...

그래도 안되어 찾고 찾다가 write.update.php에 제한이 있더라구요...

물론 웹에디터에도 제한이 있긴 하지만...

 

결국 db 필드 type을 longtext로 해도 꿈적도 안하더라구요.. 저 제한때문에...

숨은 그림찾기 한참 했어요..

 

추천0
스폰서링크

댓글 23개

그 이유는 아닙니다. 특별한 고객은 필요해서 그 부분을 크게 변경했습니다.
대용량 입력을 원하는 고객은 수정이 필요합니다.
죄송합니다.
소스를 보니 제한적인 요소가 있네요.
이건 좀더 고민 할 문제 같아요 독립서버가 아니라면 ...
법용이라면 호스팅환경등을 고려한 처사가 아닐까요?
글쎄요... 그것은 프로그램 다음에 고려할 문제죠..
mysql 필드의 데이타 타입이 메모리에 따라 여러 개인 이유는 필요하기 때문 아닐까요?
mediumtext도 있고, longtext도 있는데 사용하지 못한다면 왜 오래전부터 있을까요?
아마도 /bbs/write.update.php 에 사이즈 제한을 둔 것은 다른 의미가 있지 않을까 생각했어요..
대부분의 사람들은 65,536만 부여해도 전혀 문제가 안되기도 하구요...
예전에 오라클 디비 저장 부분때문에 blob 처리에 대해 프레임웍 개발사와 논쟁을 한 경험때문에
제가 오지랍을 떨었나 보네요
제 생각에는 변함이 없으나 좀더 좋은 개념의 처리방식이 생긴다면 좋겠어요
범용과 호스팅환경을 고려해야 한다면 어떤것이 좋을지는 고민해 봐야죠
데이터베이스 엔진등 모든것이 발달하고 있으니까요
논쟁은 바람직하죠.. 그러면서 저도 많이 배우니까요.. 그리고 이게 대부분의 사람에겐 전혀 문제가 되지 않을 겁니다.. 아주 특별한 경우만 이 용량을 넘어서는 입력을 원할 테니까요..
그누보드5 게시판에서 일반텍스트를 3~4페이지 분량 넣으면 더 이상 입력이 안되고 짤려 저장되는 것을 경험하게 될 겁니다. 아마도 3~4페이지가 아닐 수도 있구요. 좀 스크롤된다 싶으니 짤리더라구요..
제생각은 속도때문이 아닐까 추측해봅니다
그리고 데이타를 다룰때(이전,복구)
텍스트 데이타라면 innoDb보다 MyIsam이 다루기가 수월하더군요
blob도 좋지만 대용량을 php를 돌리는 일반적인 웹서버에서 처리한다는건 무리가 아닐까 싶습니다

말씀하신대로 고용량,대용량이 필요하기도 하지만
그런고객은 단독서버 혹은 멀티서버로
db도 별도로 설계하는게 맞는것 같고
그럼에도 한 필드에 그크기의 데이타를 다 넣는것은 잘 고려하여 설계하는게 맞지않을까 싶네요

65535
MyIsam에서 사용가능한 테이블의 행 제한 이기도 하더군요

wr_content 도 같은 제약에 걸려있네요
text 의 maxlength 가 65535 bytes 로 확인됩니다


간혹 문서를 찾다보면 cms는 mediumtext 이상으로 하는게 좋을것이라 제안하네요

리자님의 현명하신 설계라 봅니다
웹편집기 즉 에디터는 사용자 컴퓨터에서 실행되어지는 프로그램입니다.
즉 불특정 다수의 환경을 고려해야 하지요 거기에 오에스(윈도우등등) 서로 주고 받는데에는 한계를 극복하려면 돈이 듭니다.
웹편집기 자체를 고치라는 것이 아니라 필요한 사람만 고쳐쓰면 된다는 얘기입니다..
혹 사용하시는 분이 있다면 웹편집기에서도 그 부분을 수정해야 한다는 정보를 알려드린 것입니다.
Type      | Maximum length
-----------+-------------------------------------
  TINYTEXT    |          255 (2 8−1) bytes
      TEXT      |        65,535 (216−1) bytes = 64 KiB
MEDIUMTEXT |    16,777,215 (224−1) bytes = 16 MiB
  LONGTEXT  | 4,294,967,295 (232−1) bytes =  4 GiB

ㅎㅎ 물론 65,535를 넘기는 것이 일반적인 사례는 아니죠...
그리고 varchar도 최대사이즈가 65,535입니다.(MySQL 5.0.3이후버전부터)
지금 저장장치가 대용량으로 변했는데 과거의 문서구조 65,535에 묶여 있는 것은 아닌가 생각이 들 긴 합니다. 과거 온라인 문서의 한계가 64k였던 것이 계속 습관이 되었다고 생각이 듭니다.
그렇게 생각하실 수 도 있습니다만...저도 딱히 답을 드리긴 어렵네요
저도 독립 디비서버에 이미지서버 웹서버 등을 운엉하고 있지만 항상 고민거리는 많습니다.
기술적이거나 원론적인건 현실에서는 추상적이고 효율적 운영방법은 항상 딜레마이지오.
그래서 채산성을 따지기도 하고요
전체 173,016 |RSS
자유게시판 내용 검색

회원로그인

(주)에스아이알소프트 (06253) 서울특별시 강남구 도곡로1길 14, 6층 624호 (역삼동, 삼일프라자) 대표메일:admin@sir.kr
사업자등록번호:217-81-36347 대표:홍석명 통신판매업신고번호:2014-서울강남-02098호 개인정보보호책임자:이총

© SIRSOFT