Podstawowe pytania T-SQL

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?

**5)**Czym różnią się jednak kreska od dwóch kresek kurzych łapkach - odpowiednio liczebność 0…1 lub 1..1 ?

**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)?

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)

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.

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