Najlepsze praktyki uzyskiwania dostępu do danych bez schematów?

Question

Korzystam z RDF, a w szczególności, jak uzyskać dostęp do informacji przechowywanych w pamięci rdf. Ogromna różnica w porównaniu z tradycyjną relacyjną bazą danych polega na braku predefiniowanego schematu: w relacyjnej bazie danych wiesz, że tabela zawiera te kolumny, i możesz technicznie odwzorować każdy wiersz na wystąpienie klasy. Klasa ma dobrze zdefiniowane metody i dobrze zdefiniowane atrybuty.

W systemie bez schematu nie wiesz, jakie dane są powiązane z daną informacją. To tak, jakby mieć tabelę bazy danych z dowolną i nieokreśloną liczbą kolumn, a każdy wiersz może zawierać dane w dowolnej liczbie tych kolumn.

Podobny do mapperów obiektów ObjectRelational, istnieją obiekty mapujące RDF obiektu. RDFAlchemy i SuRF to dwie, które teraz gram. Zasadniczo udostępniają obiekt Resource, którego metody i atrybuty są dostarczane dynamicznie. To ma sens ... jednak nie jest to takie proste. W wielu przypadkach wolisz mieć dobrze zdefiniowany interfejs i mieć większą kontrolę nad tym, co dzieje się podczas ustawiania i pobierania danych na obiekcie twojego modelu. Posiadanie takiego ogólnego dostępu utrudnia w pewnym sensie.

Inną rzeczą (i najważniejsze) zauważyłem jest to, że nawet jeśli wogóle oczekuje się, że dane schematu mniej dostarczyć dowolną informacje o zasobie, to w praktyce, że bardziej lub mniej wiem „klas informacji "które wydają się być razem. Oczywiście nie można wykluczyć obecności dodatkowych informacji, ale w niektórych przypadkach jest to wyjątek, a nie norma, chociaż wyjątek jest na tyle rozsądny, aby być zbyt uciążliwym dla rygorystycznego schematu. W rdf reprezentującym artykuł (np. Jak w kanałach RSS/ATOM) znasz warunki opisanych zasobów i możesz je odwzorować na dobrze zdefiniowany obiekt. Jeśli podasz dodatkowe informacje, możesz zdefiniować obiekt rozszerzony (odziedziczony po obiekcie podstawowym), aby zapewnić dostęp do rozszerzonych informacji. W pewnym sensie masz do czynienia z danymi bez schematu za pomocą "obiektów zorientowanych na schemat", które możesz rozszerzyć o , gdy chcesz zobaczyć szczegółowe informacje dodatkowe, którymi jesteś zainteresowany.

Moje pytanie jest związane z Państwa doświadczeniem w zakresie praktycznego stosowania w świecie pamięci masowej bez schematów. W jaki sposób mapują one do świata zorientowanego obiektowo, aby można było z niego korzystać zręcznie i nie zbliżając się zbytnio do "gołego metalu" pamięci masowej bez schematów? (w terminach RelDB, bez użycia zbyt dużej ilości instrukcji SQL i bezproblemowej ingerencji w strukturę tabeli)

Czy dostęp jest skazany na bardzo ogólny (np. "atrybuty wtyczek" w SuRF to najwyższy, najbardziej wyspecjalizowany poziom, jaki można mieć dostęp do danych) lub posiadanie specjalistycznych klas dla określonych uzgodnionych wygodnych schematów jest również dobrym podejściem, wprowadzając jednak ryzyko rozprzestrzeniania klas w celu uzyskania dostępu do nowych i nieoczekiwanych powiązanych danych?

Answer 1

Myślę, że moja krótka odpowiedź byłaby "nie". Jestem trochę greybeard i zrobiłem wiele mapowania danych XML w relacyjnych bazach danych. Jeśli zdecydujesz się użyć takiej bazy danych, będziesz musiał nieustannie sprawdzać swoje dane. Będziesz także potrzebował bardzo surowej dyscypliny, aby uniknąć posiadania baz danych o niewielkim stopniu podobieństwa. Użycie schematu pomaga tutaj, ponieważ większość schematów XML jest zorientowanych obiektowo, a zatem rozszerzalna, co zmniejsza potrzebę analizy, aby nie tworzyć podobnych danych o odmiennych nazwach, co spowoduje, że każdy, kto ma dostęp do bazy danych, pomyśli o tobie złe myśli.

W moim osobistym doświadczeniu, jeśli robisz rzeczy, w których baza danych w sieci ma sens, przejdź do niego. Jeśli nie, tracisz wszystkie inne funkcje, jakie mogą wykonywać relacyjne bazy danych, takie jak sprawdzanie integralności, transakcje i ustawianie wyboru. Jednakże, ponieważ większość ludzi używa relacyjnej bazy danych jako magazynu obiektów, myślę, że kwestia jest dyskusyjna.

Jeśli chodzi o dostęp do tych danych, po prostu umieść je w Hashtable. Poważnie. Jeśli nigdzie nie ma schematu, nigdy nie wiesz, co tam jest. Jeśli masz schemat, możesz go użyć do generowania obiektów akcesorów, ale zyskujesz niewiele, ponieważ tracisz całą elastyczność bazowego sklepu, jednocześnie uzyskując nieelastyczność DAO (Data Access Object).

Na przykład, jeśli posiadasz Hashtable, pobieranie wartości z parsera XML jest często dość łatwe. Użytkownik definiuje typy pamięci, których zamierza używać, a następnie przechadza się po drzewie XML i umieszcza wartości w typach pamięci, przechowując typy w odpowiedniej tablicy lub tabeli. Jeśli jednak używasz DAO, skończyć się nie mogąc trywialnie przedłużyć obiektu danych, jeden z mocnych XML, i trzeba utworzyć pobierające i ustawiające dla obiektu, który zrobić

public void setter(Element e) throws NoSuchElementException { 
    try { 
     this.Name = e.getChild("Name").getValue(); 
    } catch (Exception ex) { 
     throw new NoSuchElementException("Element not found for Name: "+ex.getMessage()); 
    } 
} 

wyjątkiem , oczywiście, musisz to zrobić dla każdej wartości w tej warstwie schematu, w tym dla ładowarek i definicji dla podwarstw. I, oczywiście, kończy się znacznie większym bałaganem, jeśli używasz szybszych analizatorów, które wykorzystują wywołania zwrotne, ponieważ musisz teraz śledzić, który obiekt jest twój, kiedy tworzysz wynikowe drzewo.

Zrobiłem to wszystko, chociaż normalnie konstruuję walidator, a następnie adapter, który zapewnia dopasowanie między XML a klasą danych, a następnie proces uzgadniający w celu uzgodnienia go z bazą danych. Mimo to prawie cały kod jest generowany. Jeśli masz DTD, możesz wygenerować większość kodu Java, aby uzyskać do niego dostęp, i rób to z rozsądną wydajnością.

Po prostu utrzymywałbym dane typu freeform, networked lub hierarchic jako dane swobodne, sieciowe lub hierarchiczne.

Answer 2

Nie mam doświadczenia z schematem mniej DB w połączeniu z OOP, z mam rok doświadczenia z schematu mniej DB i skryptów. Z mojego doświadczenia wynika, że ​​może być całkiem użyteczne. DB użyłem również untyped (wszystkie arbitralne ciągi). Prowadzi to do następujących zalet:

• nie trzeba dbać o strukturze DB. Jeśli chcesz coś zapisać, po prostu zapisz. I nie musisz się martwić o typy danych, które pasują do języka skryptowego, aby łatwo dodać informacje debugowania do "obiektów" w razie potrzeby bez konieczności posiadania pustych kolumn dla większości wierszy tabeli. To pozwala nawet przechowywać ogromne porcje danych w razie potrzeby,
• nie musisz dbać o aktualizacje struktury DB. Właśnie piszesz do bazy danych nowe dane, które pochodzą z twojej nowej wersji oprogramowania.W ten sposób nie potrzebujesz administratora, aby zaktualizować strukturę tabeli i konwertować stare dane. To właśnie dzieje się w locie
• jeśli klucz dla par klucz-wartość ma meaningfull nazwę, nie trzeba dużo dokumentacji do swoich danych

Więc w moim przypadku schematu mniej DB wraz z skrypt był bardzo przydatny i był ogromnym sukcesem.

Kiedy myślisz o użyciu obiektów dla schematu mniej DB, chciałbym zachować wolność poprzez przechowywanie obiektów w hali. Dałoby to swobodę dostępu do wszystkich par klucz-wartość - bez względu na wybrany "obiekt". Dałoby Ci to również swobodę dodawania nowych par klucz-wartość w razie potrzeby.

Jeśli twoje obiekty (takie jak w kanale RSS) mają dobrze zdefiniowaną podstawę, warto wymyślić podstawowe obiekty, które obejmują dobrze zdefiniowaną bazę, ale mają też swoistą mapę haszującą dla twojej wolności.

Gdy tylko odkryjesz, że coraz więcej par klucz-wartość okazuje się być "standardowymi", po prostu zaktualizuj swój model obiektowy, aby je enkapsulować - oprogramowanie zmieni się w odpowiednią strukturę danych. Oby miało sens przeniesienie niektórych danych do tradycyjnych RMDBS w późniejszym czasie.

Nie nad inżyniera - realizować funkcje, gdy są potrzebne ...

Answer 3

powiedziałbym najlepsze praktyki dla pliku XML Schema mniej jest stworzenie schematu dla niego!

Brak schematu nie jest szczególnie przyjemny. Oznacza to, że nie można w żaden sposób sprawdzić poprawności pliku, poza wykryciem, czy jest to poprawnie sformatowany kod XML, czy nie.

Brak semantyki w pliku, co wydaje się podejrzane. Ponieważ oznaczałoby to, że nie wiesz, co powinieneś, zrobiłeś, lub włożysz w to. Jeśli tak jest, brzmi podejrzanie jak rozwiązanie w poszukiwaniu problemu.

Jeśli nie masz schematu, ponieważ nie znasz jeszcze języka schematu, spójrz na DTD. To bardzo proste. Możesz się uczyć i opanować w ciągu około godziny lub dwóch, jeśli masz narzędzie sprawdzania poprawności lub sprawdzania poprawności analizatora składni w aplikacji.

Jeśli problem, który uniemożliwia mając schematu jest to, że zasady schematu nie wydają się pasować do typów plików definicji schematu obejrzeniu tej pory, nie strach.

Chociaż pliki DTD i nawet XSD (XML Schema) są nieco sztywne, istnieją inne, bardziej elastyczne typy plików schematu. Są znacznie prostsze niż XSD, zaufajcie mi.

Proszę spojrzeć na specyfikację pliku schematu RNC (RELAX NG, compact). Pliki RNC są bardzo łatwe do odczytania i napisania przez ludzi. Istnieje kilka edytorów XML, którzy je rozumieją. Istnieją narzędzia, które będą konwertować pomiędzy formatem RELAX NG (RNG lub RNC) i innymi formatami, takimi jak DTD i XSD.

Ostatni raz zaznaczone, XHTML TR obejmował nienormatywnych plik RNC o pomoc w walidacji go, nie wspominając o udokumentowanie go jednoznacznie. RELAX NG ma elastyczność, aby to zrobić, i można go przeczytać, nie będąc częścią kolektywu Borg. W tym przypadku Borg nie jest eufemizmem Microsoft.

Jeśli potrzebujesz czegoś jeszcze bardziej elastyczne niż RELAX NG, wziąć spojrzenie Schematron. Jest to bardzo miły, oparty na regułach język sprawdzania schematu. To nie jest bardzo skomplikowane. Podobnie jak innych językach schematu, to też już od dłuższego czasu, jest dojrzały i jest uznanym standardem.

Nawet niektórzy wyżsi inżynierowie Microsoftu mieli poważne obawy dotyczące XSD. Złożoność jest wysoka, okazuje się, że nie jest w stanie wyrazić pewnych niezbyt dziwnych ustaleń dotyczących danych, jest bardzo obszerna, miesza obawy, takie jak walidacja i wartości domyślne, i tak dalej. Cokolwiek robisz, nie brzmi to zbyt dobrze do bezpośredniego wsparcia.

Program do mapowania RDF, podobnie jak narzędzia do bindowania XSD, doskonale nadaje się do utrzymywania obiektów, biorąc pod uwagę ich klasy w niektórych obsługiwanych językach programowania, takich jak Java (np. Z JAXB). Nie jest jednak jasne, czy masz jakieś zajęcia, które chcesz utrzymywać.

Istnieje kilka semantycznych technologii internetowych, takich jak OWL i RDF, które są elastyczne i bardzo dynamiczne.

Jednym z narzędzi, które możesz chcieć obejrzeć, jest Stanford's Protege. Jest dość potężny i bardzo elastyczny. Jest to po prostu semantyczne środowisko IDE i framework. Ten ostatni jest napisany w Javie, podobnie jak narzędzie. Jednak semantyczny schemat sieci i pliki danych tworzone przez Protege i edycje mogą być używane przez programy napisane w dowolnym języku. W takich plikach nie ma uprzedzeń wobec Javy.

Ponadto można znaleźć wiele semantycznych schematów internetowych za pomocą Swoogle. Może istnieć schemat, który pasuje do każdej aplikacji.

W zasadzie wymyślanie pliku schematu w jednym z wielu języków sprawdzania poprawności schematu nie jest trudne, gdy wiesz, co chcesz umieścić w pliku danych XML. Jeśli nie masz pojęcia, to jest mało prawdopodobne, że program lub osoba będzie wiedziała, co z nią zrobić, kiedy go przeczytają. W takim przypadku XML może nie być najlepszą reprezentacją pamięci. Nie jestem pewien, czy coś byłoby.

Zamiast tego możesz chcieć zrobić cokolwiek robisz w języku skryptów ogólnego przeznaczenia, dynamicznie wpisanym, jak Python lub Ruby. Można również użyć LISP, jeśli chcesz, aby twoje programy miały nie tylko nieograniczone formaty danych, ale także same mogły się modyfikować.

Inną opcją do przechowywania danych bez schematu jest logiczny język programowania. Zwykle nie mają żadnego schematu. Zamiast tego mają one ontology.

Dwa języki programowania Dużo pracowałem przy tym użyciu ontologii: CLIPS i Prolog. Dostępne są wolne, otwarte, wieloplatformowe implementacje obu.

Spójrz na SWI-Prolog; szybki, prosty i potężny. Możesz w nim zdefiniować fakty i reguły, które w razie potrzeby syntetyzują fakty. Wyciągasz dane za pomocą zapytań. Prolog był rzeczywiście inspiracją dla RDF, kiedy został stworzony, w latach 90., jak pamiętam. Oryginalna dokumentacja RDF używana do częstych odwołań do Prolog. Jeśli chcesz "odkryć" lub "przeanalizować" lub "znaleźć" rzeczy o faktach w swojej ontologii, Prolog jest bardzo dobrym językiem do pisania takich aplikacji. Jest także przydatny do analizowania języka naturalnego.

CLIPS jest również przyjemny, jeśli chcesz rozwiązać problem faktów w swojej ontologii. Jest dobrze dostosowany do organizacji, rozwiązywania problemów i aplikacji związanych z konfiguracją.

Jeśli schematy nie są twoją rzeczą, być może to ontologie. Jeśli nie, być może powinieneś po prostu użyć dynamicznie wpisanego języka skryptowego i przechowywać dane przechowywane w złożonych obiektach przy użyciu map i list do plików przy użyciu ich standardowych mechanizmów trwałości.

Answer 4

Użyj MongoDB lub innych baz danych nosql. Zobacz także ten blog pod adresem: Why I think Mongo is to Databases what Rails was to Framework.