복잡한 데이터에 액세스 / 조작 할 때 여러 개의 작은 조각 또는 하나의 큰 덩어리로 저장하는 것이 더 낫습니까?

기타 탭과 같이 상당히 복잡한 데이터를 조작하는 웹 앱을 만들고 있습니다.

    As a reference, guitar tabs look like this:
Eb|-------------------------------------------------------------------------|
Bb|-------------------------------------------------------------------------|
Gb|--5-5-5-5----------------------------------------------------------------|
Db|--5-5-5-5--3-3-3-3--7-7-7-7--5-5-5-5--2-2-2-2--3-3-3-3--2-2-2-2--5-5-5-5-|
Ab|--3-3-3-3--3-3-3-3--7-7-7-7--5-5-5-5--2-2-2-2--3-3-3-3--2-2-2-2--5-5-5-5-|
Eb|-----------1-1-1-1--5-5-5-5--3-3-3-3--0-0-0-0--1-1-1-1--0-0-0-0--3-3-3-3-|

이 데이터를 큰 청크로 저장하거나 분리하여 "참고 별"로 저장하는 것이 성능면에서 더 효율적입니까?

As a use case:
User changes first chord from:       to:
                         Eb|---   Eb|---
                         Bb|---   Bb|---
                         Gb|--5   Gb|--4
                         Db|--5   Db|--4
                         Ab|--3   Ab|--2
                         Eb|---   Eb|---

블록으로 저장하면 탭을 조작하는 코드가 훨씬 복잡해야합니다. 메모로 메모를 저장하면 데이터베이스에 더 많이 액세스해야합니다. 어떤 방법이 더 효율적입니까? 잠재적으로 많은 사용자가 데이터를 수정하게됩니다. 최고의 웹 앱을 원합니다 . 그것이 대답에 전혀 영향을 미치지 않는다면 MySQL을 사용할 것입니다.

database-design

— 가베 윌라드
소스

무엇을 위해 더 나은가? 공간 절약? CPU 파워? IO? 다른 것?

— Oded

글쎄, 그것은 웹 응용 프로그램입니다. 많은 사용자가 잠재적으로 데이터를 상당히 자주 수정하려고합니다. 당신이 언급 한 많은 요인이 다르게 영향을 줄 것이라고 상상합니다. 나는 그 특성에 익숙하지 않다. 그것이 부분적으로 내가 여기에 묻는 이유입니다.

— Gabe Willard

무엇을 최적화하고 있는지 모른다면 어떻게 대답 할 수 있습니까? 문제는-특정 문제가있는 경우 먼저 작성하고 정렬 방법을 요청하십시오.

— Oded

데이터베이스를 작성하기 전에 설계하지 않습니까? 내 질문은 데이터베이스 디자인에 관한 것입니다. 문제를 해결하지 못했습니다. 나는 아직 디버깅 단계에 있지 않으며, 그래도 프로그래머가 아닌 StackOverflow로 이동합니다. FAQ : 프로그래머는 알고리즘 및 데이터 구조 개념, 디자인 패턴, 소프트웨어 아키텍처, 소프트웨어 엔지니어링 등을 다루고 있습니다. 병목 현상을 해결하지는 않습니다.

— Gabe Willard

+1 매우 흥미로운 문제와 좋은 직업 삽화 유용한 유스 케이스. 기타 탭 앱을 개발할 수있는 좋은 변명이 있었으면 좋겠습니다.

— Evan Plaice

답변:

작업 수는 어느 쪽이든 동일합니다. 노래에 대한 모든 코드를 얻기 위해 하나의 쿼리를 수행 한 다음 변경할 때마다 하나의 업데이트를 수행합니다. 차이점은 실제로 업데이트 크기에 있습니다. 차단 방법 을 사용하면 코드를 변경할 때마다 전체 곡 을 저장해야합니다 . 개별 방법을 사용하면 업데이트가 더 작고 전체적으로 더 효율적이지만 차이는 무시할 수 있습니다.

고려해야 할 또 다른 사항은 노트 별 방법이보다 정규화되어 있으므로 더 많은 쿼리 옵션을 사용할 수 있다는 것입니다. 예를 들어 초보자는 배울 노래를 검색 할 때 모르는 코드를 걸러 내거나 누군가 노래 제목을 모르는 경우 시작 코드를 기준으로 검색을 허용 할 수 있습니다. 지금 이러한 기능을 계획하지 않더라도 나중에 원하는 것을 원한다면 데이터베이스를 변경하는 것은 큰 고통이 될 것입니다.

— 칼 빌레펠트
소스

일반적으로 몇 가지 이유로 더 많은 정규화가 좋습니다.

데이터 중복이 줄어들어 실제 데이터베이스 크기가 더 작아집니다.
더 나은 데이터 무결성-외래 키를 사용하여 특정 요구 사항을 적용 할 수 있습니다.
식별 한 간단한 업데이트 코드
더 많은 색인 가능한 액세스가 데이터의 하위 집합으로 라우팅됩니다.

단점 ( 여기에 잘 설명되어 있음 )에는 다음이 포함됩니다.

정규화는 공간을 절약하지만 공간은 저렴합니다.
정규화는 업데이트를 단순화하지만 읽기가 더 일반적입니다.
정규화되지 않은 스키마를 사용하면 일반적으로 성능이 향상됩니다.

좀 더 표준화 된 디자인으로 시작하는 것이 좋으며 성능 문제가 발생하는 경우에만 비정규 화를 고려하십시오.

— 마이크 파트 리지
소스

기타 탭 데이터베이스를 사용하면 단순성, 일관성 및 무결성이 성능을 능가합니다. 그래서 내가 생각해 낼 수있는 가장 간단한 정규화 된 스키마를 사용하겠습니다.

— 9000

스토리지를 가장 쉽게 사용할 수있게하고 나사를 조일 수있을만큼 힘듭니다. 합리적으로 표준화 된 스키마를 사용하십시오. 가능하면 첫 번째 릴리스에 필요한 것 이외의 사용법을 배제하지 않는 스키마를 사용하십시오.

경우 모두 당신이 필요로하는 특정 노래에 대한 탭을 보여주는 것입니다, 당신은 하나 개의 문서로를 가져 오는 (MongoDB를 같은) 문서 중심의 DB에 6 튜플을 많이 저장할 수 있습니다.

RDBMS에서 비슷한 테이블에 다음과 같이 저장합니다.

table tab_column (
  song_id integer not null foreign key references song(id),
  ordinal integer not null, -- position in the tabulature
  s1 number(2), -- position on 1st string
  ...
  s6 number(2),
  primary key(song_id, ordinal)
)

RDBMS는 노래를 표시하는 데 필요한 것과 같은 간단한 쿼리에 적합합니다.

select * from tab_column
where song_id = :song_id
order by ordinal;

limit및을 사용 offset하면 노래의 일부를 표시 할 수 있습니다.

나중에 tab_column코드를 인식 할 수 있으면 명명 된 코드를 나열하는 테이블에 쉽게 연결할 수 있습니다.

이것은 아마도 가장 간단한 스키마 일 것입니다. 시작하겠습니다.

— 9000
소스