Podstawowe pytania T-SQL

0

Cześć, mam kilka pytań dotyczących projektowania baz danych, będę wdzięczny za odpowiedzi, bo w sieci nie zawsze jest jednoznaczna odpowiedź. Na rozgrzewkę, pierwsze prostsze ;)

1) Czy przy ustawieniu Primary Key jest not null? Gdzieniegdzie widziałem, na schematach przy PK dopisywany jest not null, a gdzieniegdzie nie, chciałbym potwierdzić.
2) Czy tworząc tabele muszę definiować szczegóły FK np. unikalność, not null itp. Czy w momencie ustawienia relacji samo niejako przekopiuje te ustawienia z FK<->PK odpowiedniej tabeli? Generalnie czy jak ustawiamy relację PK->FK to czy kolumna, która staje się FK przyjmuje np. typ danych, not null itp. według kolumn PK z tabeli źródłowej?
3) Jaki wybrać typ danych na sam ROK (4 znaki)? Rozpatruje przypadek gdy nie ma pola date, z którego mogę wyciągnąć YEAR. Poczytałem w google, że int(4) oraz decimal(4,0) nie zabezpieczy nas przed nadmiarem/niedomiarem danych. Czy da się ograniczyć ilość wpisanych cyfr dla int/tinyint, może za pomocą Check? Widziałem, też na poważnej bazie produkcyjnej char(4).
4) Przy rysowaniu relacji w notacji np. crow's foot tzw. "kurzych łapek" co oznacza przerywana linia?
screenshot-20210318120719.png
5)Czym różnią się jednak kreska od dwóch kresek kurzych łapkach - odpowiednio liczebność 0…1 lub 1..1 ?
screenshot-20210318121112.png
6) Jak jest dobra praktyka nazywania FK, PK, constraint itd.? Widziałem numerki, opisy łączonych tabel itp.?
7) Co w momencie gdy usuniemy schemat a są do niego przypięte tabele? Czy MSSQL zezwoli na taką operację?
8) Czy można stworzyć 1 zapytanie z podzapytaniami zapewne, które jednocześnie utworzy (create) tabelę a następnie zrobić wsad (insert) na podstawie danych z już istniejącej (select) + jakiś pojedynczy convert danych np. z int->tinyint oraz char(255)->varchar(50)?

2
  1. Nie pamiętam jak jest, ale dopuszczeni nulla na PK jest totalnie bez sensu.
  2. Tak musisz zdefiniować dokładnie wszystko, jak chcesz. Nic nie będzie dziedziczone z PK
  3. Najlepiej inta i na checku go ograniczyć.
    4 i 5 poczytaj sobie o notacjach - mam wrażenie, że chodzi ci o diagramy ERD, ale niczego pewny teraz już być nie można.
  4. Nie ma standardu. Dla mnie trochę bez znaczenia jak się będzie nazywał i tak patrze w definicję.
  5. A co na to dokumentacja?
  6. https://www.w3schools.com/sql/sql_insert_into_select.asp
2

AD 5. Tak, jest dobrą praktyką stosowanie własnych nazw wszelkich CONSTRAINT. Zwłaszcza, gdy po paru latach wyrobisz sobie odpowiedni sposób nazewnictwa. Nie masz potem problemów z ich usuwaniem, bądź modyfikowaniem - nie musisz używać kobyły do graficznego oglądania tabeli, a wystarczy linia poleceń... (nie mówię tylko o MS SQL)

2

ja tylko uściślę :)

  1. nie kojarzę żadnej bazy, która by dopuszczała null na PK
  2. o ile PK nie może być null (patrz pkt 1) to pole FK jak najbardziej tak
  3. można (tak jak podał @UglyMan ) ale taka tabela będzie goła - bez indeksów, PK, FK, itp.
2

ad. 1 Jak będziesz chciał zalozyć PK na polu z dopuszczalnym nullem to baza wywali komunikat, że nie mozna tego zrobić
ad. 7nie mozna usunąć schematu z obiektami
ad. 8 można:

select kolumna, convert(int,kolumna2 into nazwanowejtabeli from nazwatabeliźródłowej

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0