Dylemat nazywania tabel: nazwy w liczbie pojedynczej i mnogiej [zamknięte]

Academia twierdzi, że nazwy tabel powinny być liczbą pojedynczą jednostki, której przechowują atrybuty.

Nie lubię T-SQL, który wymaga nawiasów kwadratowych wokół nazw, ale zmieniłem nazwę Userstabeli na liczbę pojedynczą, na zawsze skazując osoby używające tej tabeli, aby czasami musiały używać nawiasów.

Czuję, że lepiej jest pozostać w liczbie pojedynczej, ale mam wrażenie, że nawiasy oznaczają niepożądane, takie jak nazwy kolumn ze spacjami itp.

Powinienem zostać czy pójść?

Inni dali całkiem dobre odpowiedzi, jeśli chodzi o „standardy”, ale chciałem tylko dodać to ... Czy to możliwe, że „Użytkownik” (lub „Użytkownicy”) nie jest w rzeczywistości pełnym opisem danych przechowywanych w tabeli ? Nie dlatego, że powinieneś zbytnio zwariować na punkcie nazw tabel i ich specyfiki, ale być może bardziej odpowiednie byłoby coś takiego jak „Widget_Users” (gdzie „Widget” to nazwa Twojej aplikacji lub strony internetowej).

Miałem to samo pytanie i po przeczytaniu wszystkich odpowiedzi tutaj zdecydowanie pozostaję przy SINGULAR, powody:

Powód 1 (koncepcja). Możesz pomyśleć o torbie zawierającej jabłka takie jak „AppleBag”, nie ma znaczenia, czy zawiera 0, 1 czy milion jabłek, zawsze jest to ta sama torba. Tabele to po prostu to, że pojemniki, nazwa tabeli musi opisywać, co zawiera, a nie ile danych zawiera. Ponadto pojęcie liczby mnogiej dotyczy bardziej języka mówionego (w rzeczywistości w celu ustalenia, czy istnieje jeden czy więcej).

Powód 2 . (Wygoda). łatwiej jest wyjść z pojedynczymi nazwami niż z mnogimi. Obiekty mogą mieć nieregularne liczby mnogie lub wcale, ale zawsze będą miały liczbę pojedynczą (z kilkoma wyjątkami, takimi jak Wiadomości).

• Klient
• Zamówienie
• Użytkownik
• Status
• Aktualności

Powód 3 . (Estetyka i porządek). Zwłaszcza w scenariuszach master-detail, to czyta się lepiej, lepiej wyrównuje się według nazwy i ma bardziej logiczną kolejność (Master pierwszy, Detail drugi):

• 1. zamówienie
• 2. Zamówienie Szczegóły

W porównaniu do:

• 1. Szczegóły zamówienia
• 2. Zamówienia

Powód 4 (prostota). Podsumowując, nazwy tabel, klucze podstawowe, relacje, klasy jednostek ... lepiej być świadomym tylko jednej nazwy (liczba pojedyncza) zamiast dwóch (klasa pojedyncza, tabela w liczbie mnogiej, pole pojedyncze, liczba pojedyncza-liczba mnoga master-detail .. .)

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

Gdy już wiesz, że masz do czynienia z „klientem”, możesz być pewien, że użyjesz tego samego słowa do wszystkich potrzeb związanych z interakcją z bazą danych.

Powód 5 . (Globalizacja). Świat staje się coraz mniejszy, możesz mieć zespół różnych narodowości, nie każdy ma angielski jako język ojczysty. Łatwiej byłoby programistom w innym języku angielskim myśleć o „repozytorium” niż o „repozytoriach” lub „statusie” zamiast „statusach”. Posiadanie pojedynczych nazw może prowadzić do mniejszej liczby błędów spowodowanych literówkami, oszczędzaj czas, nie myśląc „czy to dziecko czy dzieci?”, A tym samym poprawiając wydajność.

Powód 6 . (Dlaczego nie?). Może nawet zaoszczędzić czas pisania, zaoszczędzić miejsce na dysku, a nawet wydłużyć klawiaturę komputera!

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Zapisałeś 3 litery, 3 bajty, 3 dodatkowe naciśnięcia klawiatury :)

I wreszcie, możesz nazwać tych, którzy mają problemy z zarezerwowanymi nazwami, takimi jak:

• Użytkownik> LoginUser, AppUser, SystemUser, CMSUser, ...

Lub użyj niesławnych nawiasów kwadratowych [Użytkownik]

Jeśli korzystasz z narzędzi mapowania obiektowego lub będzie w przyszłości, sugeruję Singular .

Niektóre narzędzia, takie jak LLBLGen, mogą automatycznie korygować nazwy w liczbie mnogiej, takie jak Użytkownicy dla Użytkownika, bez zmiany samej nazwy tabeli. Dlaczego to ma znaczenie? Ponieważ po zmapowaniu chcesz, aby wyglądał jak User.Name zamiast Users.Name lub gorzej z niektórych moich starych tabel baz danych o nazwie tblUsers.strName, co jest po prostu mylące w kodzie.

Moją nową ogólną zasadą jest ocena, jak będzie wyglądać po przekształceniu w obiekt.

jedna tabela, którą znalazłem, która nie pasuje do nowej nazwy, której używam, to UsersInRoles. Ale zawsze będzie tych kilka wyjątków i nawet w tym przypadku wygląda dobrze jako UsersInRoles.Username.

Wolę używać niezmienionego rzeczownika, który po angielsku bywa osobliwy.

Odmienianie numeru nazwy tabeli powoduje problemy ortograficzne (jak pokazuje wiele innych odpowiedzi), ale wybranie takiej opcji, ponieważ tabele zwykle zawierają wiele wierszy, jest również semantycznie pełne dziur. Jest to bardziej oczywiste, jeśli weźmiemy pod uwagę język, który odmienia rzeczowniki na podstawie wielkości liter (jak większość):

Ponieważ zwykle robimy coś z wierszami, dlaczego nie umieścić nazwy w bierniku? Jeśli mamy tabelę, do której piszemy więcej niż czytamy, dlaczego nie umieścić tej nazwy w celowniku? Jest to stół z czegoś, czemu nie skorzystać dopełniacz? Nie zrobilibyśmy tego, ponieważ tabela jest zdefiniowana jako abstrakcyjny kontener, który istnieje niezależnie od jego stanu lub użycia. Odmienianie rzeczownika bez dokładnego i absolutnego powodu semantycznego jest gaworzeniem.

Używanie niezmienionego rzeczownika jest proste, logiczne, regularne i niezależne od języka.

Jaka konwencja wymaga, aby tabele miały nazwy pojedyncze? Zawsze myślałem, że to liczby mnogie.

Użytkownik zostanie dodany do tabeli Użytkownicy.

Ta strona zgadza się:
http://vyaskn.tripod.com/object_naming.htm#Tables

Ta strona się nie zgadza (ale ja się z tym nie zgadzam):
http://justinsomnia.org/writings/naming_conventions.html

Jak wspomnieli inni: są to tylko wytyczne. Wybierz konwencję, która działa dla Ciebie i Twojej firmy / projektu i trzymaj się jej. Przełączanie między słowami pojedynczymi i mnogimi lub czasami skrótem, a czasem nie jest o wiele bardziej irytujące.

A może to prosty przykład:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

vs.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

SQL w drugim przypadku brzmi dziwniej niż pierwszy.

Głosuję za liczbą pojedynczą .

Jestem głęboko przekonany, że na diagramie relacji między bytami byt powinien być odzwierciedlony za pomocą pojedynczej nazwy, podobnej do pojedynczej nazwy klasy. Po utworzeniu instancji nazwa odzwierciedla jej instancję. W przypadku baz danych jednostka po przekształceniu w tabelę (zbiór jednostek lub rekordów) jest liczbą mnogą. Podmiot, Użytkownik jest wprowadzany do tabeli Użytkownicy. Zgadzam się z innymi, którzy sugerowali, że być może nazwa użytkownika może zostać zmieniona na pracownika lub coś bardziej odpowiedniego do twojego scenariusza.

Ma to wtedy większy sens w instrukcji SQL, ponieważ wybierasz z grupy rekordów, a jeśli nazwa tabeli jest pojedyncza, nie czyta się dobrze.

Trzymam się liczby pojedynczej dla nazw tabel i wszelkich bytów programujących.

Powód? Fakt, że w języku angielskim występują nieregularne formy liczby mnogiej, takie jak mysz ⇒ myszy i owce ⇒ owce . Następnie, jeśli potrzebuję kolekcji , po prostu używam myszy lub owiec i idę dalej.

Naprawdę pomaga wielu wyróżnić się i mogę łatwo i programowo określić, jak będzie wyglądać zbiór rzeczy.

Tak więc, moja zasada brzmi: wszystko jest w liczbie pojedynczej, każda kolekcja rzeczy jest w liczbie pojedynczej z dołączonym s . Pomaga również w przypadku ORM.

IMHO, nazwy tabel powinny być w liczbie mnogiej jak w przypadku klientów .

Nazwy klas powinny być pojedyncze, tak jak Klient, jeśli są odwzorowane na wiersz w tabeli Klienci .

Pojedynczy. Nie kupuję żadnego argumentu, który jest najbardziej logiczny - każda osoba uważa, że ​​jego własne preferencje są najbardziej logiczne. Bez względu na to, co robisz, jest to bałagan, wystarczy wybrać konwencję i trzymać się jej. Próbujemy zmapować język o bardzo nieregularnej gramatyce i semantyce (normalny język mówiony i pisany) na wysoce regularną (SQL) gramatykę o bardzo specyficznej semantyce.

Moim głównym argumentem jest to, że nie myślę o tabelach jako zestawie, ale o relacjach.

Tak więc AppUserrelacja mówi, które jednostki są AppUsers.

AppUserGroupRelacja mówi mi, jakie podmioty sąAppUserGroups

AppUser_AppUserGroupRelacja mówi mi, w jaki sposób AppUsersi AppUserGroupssą powiązane.

AppUserGroup_AppUserGroupRelacja mówi mi, jak AppUserGroupsi AppUserGroupszwiązane są (tzn grupy członkiem grupy).

Innymi słowy, kiedy myślę o bytach i ich powiązaniach, myślę o relacjach w liczbie pojedynczej, ale oczywiście, gdy myślę o bytach w zbiorach lub zbiorach, zbiory lub zbiory są mnogie.

Zatem w moim kodzie i schemacie bazy danych używam liczby pojedynczej. W opisach tekstowych używam liczby mnogiej dla zwiększenia czytelności - następnie używam czcionek itp., Aby odróżnić nazwę tabeli / relacji od liczby mnogiej.

Lubię myśleć o tym jako bałaganiarski, ale systematyczny - w ten sposób zawsze pojawia się systematycznie generowana nazwa relacji, którą chcę wyrazić, co jest dla mnie bardzo ważne.

Chciałbym również przejść do liczby mnogiej , a przy wspomnianym wyżej dylemacie użytkowników przyjmujemy podejście do nawiasów kwadratowych.

Robimy to, aby zapewnić jednolitość zarówno architektury bazy danych, jak i architektury aplikacji, przy podstawowym zrozumieniu, że tabela Użytkownicy jest zbiorem wartości użytkownika , podobnie jak kolekcja użytkowników w artefakcie kodu jest zbiorem obiektów użytkownika .

Posiadanie naszego zespołu danych i naszych programistów mówiących tym samym językiem pojęciowym (choć nie zawsze tymi samymi nazwami obiektów) ułatwia przekazywanie pomysłów między nimi.

Osobiście wolę używać mnogiej nazwy do przedstawienia zestawu, to po prostu „brzmi” lepiej dla mojego relacyjnego umysłu.

W tym właśnie momencie używam pojedynczych nazw, aby zdefiniować model danych dla mojej firmy, ponieważ większość osób w pracy czuje się z nim bardziej komfortowo. Czasami po prostu musisz ułatwić wszystkim życie, zamiast narzucać swoje osobiste preferencje. (tak skończyłem w tym wątku, aby uzyskać potwierdzenie, co powinno być „najlepszą praktyką” w przypadku nazewnictwa tabel)

Po przeczytaniu wszystkich argumentów w tym wątku doszedłem do jednego wniosku:

Lubię moje naleśniki z miodem, bez względu na ulubiony smak każdego. Ale jeśli gotuję dla innych ludzi, postaram się im podać coś, co im się podoba.

Pojedynczy. Nazwałbym tablicę zawierającą kilka obiektów reprezentujących wiersze użytkowników „użytkownikami”, ale tabela jest „tabelą użytkowników”. Myślenie, że tabela jest niczym innym jak zbiorem wierszy, które zawiera, jest błędne, IMO; tabela to metadane, a zestaw wierszy jest hierarchicznie dołączony do tabeli, nie jest to sama tabela.

Oczywiście używam ORM przez cały czas i pomaga to, że kod ORM napisany za pomocą nazw w liczbie mnogiej wygląda głupio.

Właściwie zawsze uważałem, że popularną konwencją jest używanie nazw w liczbie mnogiej. Do tego momentu zawsze używałem liczby mnogiej.

Rozumiem argument za pojedynczymi nazwami tabel, ale dla mnie liczba mnoga ma większy sens. Nazwa tabeli zazwyczaj opisuje jej zawartość. W znormalizowanej bazie danych każda tabela zawiera określone zestawy danych. Każdy wiersz jest jednostką, a tabela zawiera wiele jednostek. Zatem liczba mnoga dla nazwy tabeli.

Tabela samochodów miałaby nazwę samochody, a każdy rząd to samochód. Przyznaję, że sprecyzowanie tabeli wraz z polem table.fieldjest najlepszą praktyką i że posiadanie pojedynczych nazw tabel jest bardziej czytelne. Jednak w poniższych dwóch przykładach pierwszy ma większy sens:

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

Szczerze, ponownie przemyślę swoje stanowisko w tej sprawie i będę polegał na faktycznych konwencjach stosowanych przez organizację, dla której rozwijam się. Myślę jednak, że w przypadku moich osobistych konwencji będę się trzymał liczby mnogiej nazw tabel. Dla mnie ma to większy sens.

Nie lubię nazw w liczbie mnogiej, ponieważ niektóre rzeczowniki w języku angielskim nie są policzalne (woda, zupa, gotówka) lub znaczenie zmienia się, gdy je policzasz (kurczak kontra kurczak; mięso kontra ptak). Nie lubię też używać skrótów dla nazwy tabeli lub nazwy kolumny, ponieważ powoduje to dodatkowe nachylenie już i tak stromej krzywej uczenia się.

Jak na ironię, mogę zrobić Userwyjątek i nazwać go z Userspowodu USER (Transac-SQL) , ponieważ ja też nie lubię używać nawiasów wokół tabel, jeśli nie muszę.

Lubię też nazywać wszystkie kolumny identyfikatorów jako Id, nie ChickenIdlub ChickensId(co robią w tym przypadku mnisi faceci?).

Wszystko to dlatego, że nie mam właściwego szacunku dla systemów baz danych, po prostu ponownie stosuję wiedzę opartą na jednym kucyku z konwencjami nazewnictwa OO, takimi jak Java z przyzwyczajenia i lenistwa. Chciałbym, żeby była lepsza obsługa IDE dla skomplikowanego SQL.

Działamy według podobnych standardów, gdy skrypt wymaga [] wokół nazw i, w stosownych przypadkach, kwalifikatorów schematu - przede wszystkim zabezpiecza twoje zakłady przed przyszłymi chwytaniem nazw przez składnię SQL.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

To uratowało nasze dusze w przeszłości - niektóre z naszych systemów baz danych pracowały ponad 10 lat od SQL 6.0 do SQL 2005 - znacznie wcześniej niż zamierzały.

Tabele: liczba mnoga

W tabeli użytkowników znajduje się wielu użytkowników.

Modele: pojedyncze

Pojedynczego użytkownika można wybrać z tabeli użytkowników.

Kontrolery: liczba mnoga

http://myapp.com/users wyświetli listę wielu użytkowników.

W każdym razie to moje zdanie.

Jestem fanem pojedynczych nazw tabel, ponieważ ułatwiają czytanie moich diagramów ER przy użyciu składni CASE, ale czytając te odpowiedzi, mam wrażenie, że nigdy nie przyjął się zbyt dobrze? Ja osobiście to uwielbiam. Jest dobry przegląd z przykładami tego, jak czytelne mogą być twoje modele, kiedy używasz pojedynczych nazw tabel, dodajesz czasowniki akcji do twoich relacji i tworzysz dobre zdania dla każdej relacji. To trochę przesada w bazie danych zawierającej 20 tabel, ale jeśli masz bazę danych z setkami tabel i złożoną konstrukcję, jak deweloperzy kiedykolwiek to zrozumieją bez dobrego czytelnego schematu?

http://www.aisintl.com/case/method.html

Jeśli chodzi o prefiksowanie tabel i widoków, absolutnie nie znoszę tej praktyki. Nie udzielaj żadnej informacji, zanim przekażesz potencjalnie złe informacje. Każdy, kto przegląda bazę danych obiektów, może dość łatwo odróżnić tabelę od widoku, ale jeśli mam tabelę o nazwie tblUsers, z jakiegoś powodu decyduję się na restrukturyzację w przyszłości na dwie tabele, z widokiem ujednolicającym je, aby nie złamać starego kodu Mam teraz widok o nazwie tblUsers. W tym momencie pozostały mi dwie nieprzyjemne opcje, pozostaw widok nazwany z prefiksem tbl, który może wprowadzić w błąd niektórych programistów lub wymusić przepisanie innej warstwy, warstwy środkowej lub aplikacji, aby odwoływały się do mojej nowej struktury lub nazwy viewUsers. To neguje dużą część wartości wyświetleń IMHO.

System tables/viewssamego serwera ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, itd.) Są prawie zawsze w liczbie mnogiej. Wydaje mi się, że dla zachowania spójności podążałbym za nimi.

Jeśli spojrzymy na MS SQL Server'stabele systemowe, znajdują się ich nazwy przypisane przez Microsoftplural .

Tabele systemowe Oracle są nazywane singular . Chociaż kilka z nich jest w liczbie mnogiej. Oracle zaleca liczbę mnogą dla nazw tabel zdefiniowanych przez użytkownika. To nie ma sensu, że polecają jedną rzecz i podążają za drugą. To, że architekci tych dwóch gigantów oprogramowania nazwali swoje stoły przy użyciu różnych konwencji, również nie ma większego sensu ... W końcu, co to za faceci ... doktoranci?

Pamiętam, że w środowisku akademickim zalecenie było osobliwe.

Na przykład, gdy mówimy:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

może b / c każdy IDjest wybrany z konkretnego pojedynczego rzędu ...?

Może to być trochę zbędne, ale sugerowałbym ostrożność. Niekoniecznie dlatego, że zmiana nazw tabel jest zła, ale standaryzacja jest właśnie taka; standard - ta baza danych może być już „znormalizowana”, jednak źle :) - Sugerowałbym spójność, aby być lepszym celem, biorąc pod uwagę, że ta baza danych już istnieje i prawdopodobnie składa się z więcej niż 2 tabel.

O ile nie możesz ujednolicić całej bazy danych lub przynajmniej planujesz pracować nad tym celem, podejrzewam, że nazwy tabel są tylko wierzchołkiem góry lodowej i koncentrowanie się na zadaniu, znosząc ból źle nazwanych obiektów, może być twój najlepszy interes -

Praktyczna konsekwencja bywa czasem najlepszym standardem ... :)

my2cents ---

Możliwe alternatywy:

• Zmień nazwę tabeli SystemUser
• Użyj nawiasów
• Zachowaj nazwy tabel w liczbie mnogiej.

IMO za pomocą nawiasów jest technicznie najbezpieczniejszym podejściem, choć jest nieco kłopotliwe. IMO to 6 z jednego, pół tuzina innych, a twoje rozwiązanie naprawdę sprowadza się do preferencji osobistych / zespołowych.

Moje podejście jest semantyką w zależności od tego, jak zdefiniujesz swój kontener. Na przykład „worek jabłek” lub po prostu „jabłka” lub „worek jabłek” lub „jabłko”.

Przykład: tabela „college” może zawierać 0 lub więcej szkół, tabela „college” może zawierać 0 lub więcej szkół

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Doszedłem do wniosku, że jedno z nich jest w porządku, ale musisz zdefiniować, w jaki sposób (lub osoby wchodzące z nim w interakcje) podejdziesz, odnosząc się do tabel; „tabela toporów” lub „tabela xs”

Jak wspomnieli tu inni, konwencje powinny być narzędziem zwiększającym łatwość użycia i czytelność. Nie jako kajdany lub klub dla deweloperów tortur.

To powiedziawszy, moje osobiste preferencje to używanie pojedynczych nazw dla tabel i kolumn. Prawdopodobnie pochodzi to z mojego programowania. Nazwy klas są generalnie pojedyncze, chyba że są jakimś zbiorem. W mojej pamięci przechowuję lub czytam poszczególne rekordy w danej tabeli, więc liczba pojedyncza ma dla mnie sens.

Ta praktyka pozwala mi również rezerwować nazwy tabel w liczbie mnogiej dla tych, które przechowują relacje wiele do wielu między moimi obiektami.

Staram się również unikać słów zastrzeżonych w nazwach tabel i kolumn. W omawianym przypadku bardziej sensowne jest przeciwstawienie się pojedynczej konwencji dla Użytkowników, aby uniknąć konieczności enkapsulacji tabeli, która używa zarezerwowanego słowa Użytkownika.

Lubię używać prefiksów w ograniczony sposób (tbl dla nazw tabel, sp_ dla nazw proc itp.), Choć wielu uważa, że ​​to dodaje bałaganu. Wolę także nazwy CamelBack niż podkreślenia, ponieważ zawsze wpisuję nazwę, naciskając + zamiast zamiast _. Wielu innych się nie zgadza.

Oto kolejny dobry link do wytycznych konwencji nazewnictwa: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Pamiętaj, że najważniejszym czynnikiem w konwencji jest to, że ma ona sens dla osób wchodzących w interakcję z bazą danych, o której mowa. W przypadku konwencji nazewnictwa nie ma „jednego pierścienia, który rządzi nimi wszystkimi”.

Myślę, że używanie liczby pojedynczej było tym, czego nauczono nas na uniwersytecie. Ale jednocześnie można argumentować, że w przeciwieństwie do programowania obiektowego tabela nie jest instancją jej rekordów.

Myślę, że obecnie przechylam się na rzecz liczby pojedynczej z powodu mnogich nieprawidłowości w języku angielskim. W języku niemieckim jest jeszcze gorzej z powodu braku spójnych form liczby mnogiej - czasami nie można stwierdzić, czy słowo jest liczbą mnogą, czy nie bez określonego artykułu przed nim (der / die / das). W językach chińskich i tak nie ma form liczby mnogiej.

Kiedyś użyłem „Koleś” w tabeli użytkowników - ta sama krótka liczba znaków, brak konfliktu ze słowami kluczowymi, wciąż odniesienie do zwykłego człowieka. Gdybym nie martwił się dusznymi głowami, które mogą zobaczyć kod, zachowałbym go w ten sposób.

Zawsze używałem liczby pojedynczej po prostu dlatego, że mnie tego nauczono. Jednak podczas tworzenia nowego schematu niedawno, po raz pierwszy od dłuższego czasu, aktywnie zdecydowałem się utrzymać tę konwencję tylko dlatego, że ... jest krótsza. Dodanie „s” na końcu każdej nazwy tabeli wydaje mi się równie bezużyteczne, jak dodanie „tbl_” przed każdym.

Zawsze myślałem, że to głupia konwencja. Używam nazw tabel w liczbie mnogiej.

(Uważam, że uzasadnieniem tej zasady jest to, że ułatwia generatorom kodów ORM tworzenie klas obiektów i kolekcji, ponieważ łatwiej jest utworzyć liczbę mnogą z nazwy pojedynczej niż odwrotnie)

Używam tylko rzeczowników w nazwach tabel, które są tak samo pisane, zarówno w liczbie pojedynczej, jak i mnogiej:

łoś ryba jeleń samolot sam spodnie szorty okulary nożyczki gatunki potomstwo

Nie widziałem tego jasno wyrażonego w żadnej z poprzednich odpowiedzi. Wielu programistów nie bierze pod uwagę formalnej definicji podczas pracy z tabelami. Często komunikujemy się intuicyjnie w kategoriach „zapisów” lub „wierszy”. Jednak, z pewnymi wyjątkami dotyczącymi relacji zdenormalizowanych, tabele są zwykle projektowane tak, aby relacja między atrybutami niekluczowymi a kluczem stanowiła ustawioną funkcję teoretyczną.

Funkcję można zdefiniować jako podzbiór produktu krzyżowego między dwoma zestawami, w którym każdy element zestawu kluczy występuje najwyżej raz w odwzorowaniu. Stąd terminologia wynikająca z tej perspektywy wydaje się być pojedyncza. Widzimy tę samą konwencję w liczbie pojedynczej (lub przynajmniej w liczbie mnogiej) w innych teoriach matematycznych i obliczeniowych obejmujących funkcje (na przykład rachunek algebry i lambda).