2009-04-08 2 views
1

DB에 삽입하기 전에 데이터를 포맷하는 것이 더 좋은지, 아니면 데이터를 꺼낼 때 데이터를 포맷하는 것이 더 나은지 결코 결정할 수 없습니다.데이터베이스에 삽입하기 전이나 후에 데이터를 포맷 하시겠습니까?

나는 데이터 sanitization에 대해 말하는 것이 아닙니다. SQL 인젝션을 방지하기 위해 우리 모두 알고 있습니다. 나는 사용자가 당신에게 URL을 주었고 그것 앞에 http : //가 없으면 그것을 DB에 삽입하기 전에 추가할까요? 큰 뭉치의 텍스트 서식 지정과 같은 더 복잡한 일은 어떨까요? 그 전후에 HTML로 마크 업 (또는 스트립 다운)하고 싶습니까? 나중에 마음이 바뀌어 다르게 포맷하고 싶다면 어떻게해야합니까? 이미 포맷팅을했다면이 작업을 수행 할 수 없지만 포맷하지 않은 상태로 저장할 경우 할 수 있습니다 ... 그런 다음 DB에서 데이터를 가져올 때마다 추가 작업을하고 있습니다. 한 번 끝내고 그 일을 끝냈습니다.

귀하의 의견은 무엇입니까? 답변에서


는 URL을, 전화 번호, 이메일 (잘 정의 된 형식 무엇이든) 같은 것들이 일관된 형식으로 먼저 정상화해야한다는 일반적인 합의가 될 것 같습니다. 텍스트와 같은 것들은 일반적으로 융통성을 최대화하기 위해 원시 형식이나 조작 가능한 형식으로 남겨 두어야합니다. 속도가 문제라면 두 형식을 모두 저장할 수 있습니다.

답변

6

삽입하기 전에 표준 형식으로 URL을 표준화하는 것이 좋습니다. 모든 종류의 광범위한 서식 지정을 수행합니다 (예 : HTML 변환/파싱 등은 나에게 나쁜 생각을 안겨줍니다. 특히 나중에 프리젠 테이션 형식을 변경하려는 경우에는 항상 데이터베이스에서 "가장 원시"데이터를 사용할 수 있습니다.

모든 쿼리에서 불필요한 후 처리 작업을 피하는 대신 더 비싼 작업을 위해 개체 캐싱 또는 유사한 기술을 사용할 수 있습니다.

11

데이터베이스의 데이터가 가능한 가장 일관된 형식인지 확인하는 것이 가장 좋습니다. 이 데이터를 사용하는 앱이 여러 개있을 수 있으므로 모두 동일한 형식인지 확인하면 모든 애플리케이션에서 다른 형식을 다시 포맷해도 걱정할 필요가 없습니다.

+0

+1 : 데이터베이스는 절대적으로 일관되어야합니다. –

+0

+1 : 다른 곳에서 검색하고 재사용하려는 데이터는 중요하며 WHERE 절을 만들 수있는 데이터는 CRITICAL입니다. – ojrac

1

내 의견으로는 먼저 형식을 지정해야합니다. 삽입 대신 검색 할 때이를 선택하면 다른 응용 프로그램/스크립트가 동일한 데이터베이스에서 데이터를 사용하려고 할 때 문제가 발생할 수 있습니다. 그들은 모두 데이터를 추출 할 때 데이터 정리 방법을 알아야합니다. 당신은 잘 정의 된 항목을 수행하는 경우

1

을 따라, SSN은, 우편 번호, 전화 번호,이 반드시 등 대시 또는 도트를 포함하는 것을 의미하지 않는다 (이 형식의 저장이 그들을 그렇게 everyhting이 제거 의미 당신은 당신이 그것을 저장하기 전에 데이터를 변경하는 경우 매우 조심해야 일관성.

1

. 당신은 항상 당신이 다시 원래 사용자가 당신에게 준 정확한 텍스트 에코해야하는 상황으로 실행할 수 있습니다.

+0

어떤 상황입니까? 그리고 얼마나 자주 당신은 그들과 마주 치게됩니까? 나는 어떤 ATM도 생각할 수 없다. 그래서 나는 그것을 내 디자인에 실제로 반영하려고하지 않는다. ... –

+0

내가 그것에 부딪 쳤던 경우는 제품 SKU의 경우였다. SKU를 원래 요청자에게 피드백해야하는 EDI 프로세스가 있으며 대/소문자를 구분하는 시스템이 있습니다. –

3

여기에 두 가지 질문을하고 있습니다.

정규화는 항상 데이터베이스 삽입 전에 수행되어야합니다. 열에 URL 만 있으면 항상 먼저 정규화해야합니다.

포매팅과 관련해서는 뷰 문제이며 모델 (이 경우 DB) 문제는 아닙니다.

1

내 경향은 일반적으로 가능한 가장 유연한 형태로 데이터를 저장하는 것입니다.예를 들어 숫자는 문자열이 아닌 정수 또는 부동 소수점 형식을 사용하여 저장해야합니다. 문자열을 사용하지 않고 숫자 형식을 사용하여 수학을 수행 할 수 있기 때문에 (문자열을 숫자로 파싱하는 것이 쉽지는 않지만 큰 문제는 아닙니다.) . 아마도 더 실용적인 예가 될 수 있습니다. 날짜/시간은 문자열 대신 데이터베이스의 실제 날짜/시간 데이터 형식을 사용하여 저장해야합니다. 또한 HTML을 일반 텍스트로 변환하는 것이 더 쉬운 경우도 있습니다.이 경우 텍스트를 HTML로 저장하는 것이 좋습니다. 또는 Markdown과 같은 형식을 사용하여 HTML 또는 일반 텍스트로 쉽게 변환 할 수도 있습니다.

벡터 그래픽 형식 (SVG, EPS 등)이있는 이유는 SVG 파일이 본질적으로 이미지를 그리는 방법을 지정하는 일련의 명령입니다. 비트 맵 이미지를 모든 크기의 비트 맵 이미지로 변환하는 것은 쉽지만 반면에 비트 맵 이미지 만있는 경우 품질을 유지하면서 크기를 변경 (예 : 축소판 만들기)하기가 어려울 수 있습니다.

1

형식 및 형식이 지정되지 않은 데이터 버전을 모두 저장할 수도 있습니다. 예를 들어 미국 전화 번호를 예로 들어 봅시다. 하나의 열을 번호만으로 저장하고 하나의 열을 가장 자주 필요로하는 형식 (예 : (111) 111-1111)으로 저장하는 경우 특별한 경우를 위해 클라이언트 사양으로 쉽게 형식을 지정하거나 가장 일반적인 것을 많이 사용하지 않고 빠르게 꺼낼 수 있습니다 주조. 이것은 삽입 할 때 약간의 추가 시간이 소요됩니다 (계산 된 열을 사용하여 수행 할 수 있으므로 데이터가 어디서 왔는지에 관계없이 항상 발생합니다).

잘못된 날짜 또는 숫자가 아닌 데이터 등이 필드에 입력되지 않도록 데이터를 데이터베이스에 저장하기 전에 데이터를 제거해야합니다. 이메일은 사람들이 어떤 이유로 정크를 넣는 분야입니다. @ 기호가 없으면 저장해서는 안됩니다. 해당 필드를 사용하여 응용 프로그램을 전자 메일로 보낼 경우 특히 그렇습니다. 내 뜻을 알게되면 '비서관'또는 'aol.com'에 이메일을 보내려고하는 것은 시간 낭비입니다.

형식이 지속적으로 필요하면 삽입 또는 업데이트 할 때 한 번만 해당 형식으로 데이터를 변환하고 다시 변환 할 필요가 없습니다. 표준 형식이 변경되면 해당 시점의 모든 기존 레코드에 대한 열을 업데이트 한 다음 앞으로 나가는 새로운 형식을 사용해야합니다. 형식 및 대형 테이블을 자주 변경하거나 다른 응용 프로그램이 다른 형식을 사용하는 경우 형식이 지정되지 않은 상태로 저장하는 것이 가장 좋습니다.

관련 문제