Konwencje nazewnictwa dla bazy danych PostGIS? [Zamknięte]

Zaczynamy budować bazę danych za pomocą PostGIS. Baza danych powinna być przeznaczona dla zespołu około 5-8 badaczy, którzy często pracują z geodanymi i statystykami.

Czy ktoś ma doświadczenie z konwencjami nazewnictwa podczas konfigurowania bazy danych?

niektóre ważne rzeczy, które już wymyśliłem to:

używaj tylko małych liter
use_underscores nie spacje
nie używaj znaków specjalnych, takich jak ä, é itp
używaj tylko jednego języka (może się to wydawać trywialne, ale jesteśmy międzynarodowi)
nazwy tabel i kolumn zawsze w liczbie pojedynczej
znaleźć ustandaryzowany sposób nazywania obiektów w bazie danych, tj. format_tat_roku_źródłowego

Zwłaszcza ostatni punkt jest trudny. Przechowując własne dane, rozpoznałem, że czasami otrzymasz ogromne nazwiska. Czy byłoby więc lepiej przechowywać te informacje w łatwo dostępnych metadanych zamiast robić te ogromne nazwy, które mogą być dość denerwujące.

postgis-2.0 naming-conventions

— Dspanes
źródło

Wygląda na to, że opracowano konwencje techniczne. Nie sądzę, aby pytanie, które zadajesz, zawierało prawidłową odpowiedź, ale powiem ci, co wymyśliłem do wykorzystania w mojej organizacji.

Wolę organizować dane według grup, ponieważ, jak wszyscy wiemy, czasami metadane po prostu się nie wypełniają. Przekonałem się, że wbudowanie jednych z najbardziej podstawowych metadanych do konwencji nazewnictwa jest bardzo korzystne.

Na początek stworzyłem arkusz kalkulacyjny z głównymi kategoriami danych obsługiwanymi przez moją organizację i nadałem każdemu z nich unikalny dwuliterowy kod. Arkusz kalkulacyjny zawiera także opis kategorii i przykłady funkcji, które można znaleźć w każdej kategorii. Ten arkusz kalkulacyjny jest dostępny dla wszystkich w mojej organizacji i dołączam go do eksportowanych danych.

Każde imię zaczynam od dwuliterowego kodu, po którym następuje podkreślenie. Możesz oczywiście rozwinąć ten pomysł i zbudować go również w imieniu twórców danych. Staraj się, aby nazwy były krótkie i udokumentuj swoje metody. Oto kilka przykładów kategorii, których używam:

BI - Wnętrze budynku; BO - Granice; CT - kartograficzny; EL - cechy elewacji; EM - reakcja na awarie GE - Geologiczny; LT - Oświetlenie; PG - Siatki i układy stron; PL - Planimetryczny; RA - Raster; RD - Rysunek referencyjny; SI - Ulepszenia strony / podstawy; SU - Ankieta; UT - Narzędzia.

— Paweł
źródło

To poprawna metoda, ale naprawdę nie lubię skrótów. Jest to oczywiście kwestia osobistego gustu, ale szczególnie, jeśli pracujesz w międzynarodowym zespole, skróty te mogą wprowadzać wszystkich w błąd i zawsze będziesz potrzebować słownika danych, ilekroć będzie musiał korzystać z bazy danych. PostgreSQL pozwala, jeśli się nie mylę, 64-literowe nazwy obiektów. Wykorzystaj dobrze tę przestrzeń i stwórz najbardziej opisowe nazwy, jakie możesz znaleźć, w języku, który każdy może zrozumieć.

— George Silva,

Naprawdę podoba mi się pomysł kategoryzacji danych i omówię to z moimi kolegami. Nadal nie jestem pewien, czy nazwać dane wewnątrz bazy danych. Twoje argumenty mają całkowity sens, że dla użyteczności lepiej będzie nadać jasne nazwy wewnątrz db. Obawiam się jednak, że dokument metadanych może być mniej wykorzystywany w ten sposób. Myślałem, że nazywanie danych liczbami abstrakcyjnymi zmusi użytkowników do odniesienia się do dokumentu metadanych, a tym samym przyczyni się do tego w większym stopniu, ponieważ ludzie będą wypełniać więcej informacji na temat metadanych, ponieważ muszą się do nich odwoływać codziennie, a dokument jest już otwarty ...

— Dspanes,

@Dspanes, to interesujący argument. Tak jak powiedziałem, nie ma właściwej odpowiedzi. Ogólnie nie jestem pewien, czy podoba mi się pomysł celowego mylenia nazw, aby użytkownicy polegali na metadanych ... to jednak ciekawy pomysł.

— Paul

@Paul Tak, wydaje mi się, że to znaczy, że wiem;) Ale z tego, czego dotychczas doświadczyłem, ludzie używają tylko tego, co jest dla nich przydatne. Im bardziej są użyteczne, tym częściej ich używają i im częściej używają, tym lepsze mogą być metadane ... Chodzi o to, że nie mamy osoby, która zajmowałaby się metadanymi, dlatego potrzebujemy partycypacyjnego podejścia, w którym wszyscy wnoszą swój wkład. dokument metadanych może również przynieść korzyści, np. możesz mieć lepsze funkcje wyszukiwania i filtrowania, które pozwalają znaleźć bardziej odpowiednie dane ... ale bez wątpienia myślę też o alternatywnych podejściach do wspierania uczestnictwa ...

— Dspanes