Baza danych z "otwartym schematem" - dobry czy zły pomysł?

Większość naprawdę dużych witryn internetowych kończy się używaniem pewnego rodzaju niewiarygodnie prostego od strony bazy danych. Ma to tę zaletę, że jest szybki i skalowalny. Ma tę wadę, że wszystkie relacje, które można uzyskać bazę danych do egzekwowania automatycznie (za pomocą wyzwalaczy i tym podobne) trzeba aby wyegzekwować siebie w kodzie klienta zamiast. Utrzymanie spójności to ból szyi i prawie zawsze jest przynajmniej szansa, że Twoje dane będą niespójne, w przynajmniej przez krótki czas.

Dla portalu społecznościowego, to wartościowy kompromis. Dane, które są w większości właściwe, przez większość czasu są odpowiednie (np. kogo naprawdę obchodzi, czy liczba głosów, które otrzymujesz za przedmiot, jest naprawdę nieaktualna o 20 milisekund, gdy jest wysyłany), a utrzymanie kosztów rozsądnych podczas skalowania w celu obsługi gazyliona użytkowników ma duże znaczenie.

Zauważyłem, że nie wspominali nic o łatwości lub trudności w tworzeniu raportów na podstawie tych danych. W przypadku stosowania w wąskim zestawie okoliczności, podsłuchy mogą być korzystne. Jako centralna część większości systemów stanie się koszmarem po naciśnięciu przycisku raportowanie. Problem z EAVs polega na tym, że większość korzyści jest na początku projektu, a większość bólu jest później w analizie i raportowaniu, szczególnie ze względu na poważny brak integralności danych. "Nie musisz się martwić o klucze obce " brzmi dla mnie jak koszmar osieroconych rzędów. Dodaj w używaniu kluczy zastępczych do wszystkiego i masz splątaną morsę, która generalnie kończy się kompletnym przepisaniem