Witam, potrzebuje napisać logowanie do bazy danych. Ma ono sprawdzać login i hasło z bazy oraz pobierać poziom uprawnień jaki ma użytkownik (0-admin, 1-nauczyciel,2-uczeń). Jak ugryźć ten temat? Potrafię napisać logowanie z loginem i hasłem. Uprawnienia potrzebne są do otworzenia odpowiedniej formy do której ma dostęp użytkownik. Proszę o pomoc.
0
0
W bazie danych wypadałoby mieć tabele z rolami (rola spięta z modułami jakie ma ładować do tej roli).
W momencie logowaniu użytkownika sprawdzasz poza loginem i hasłem jeszcze po wiązaniu jak wyżej ładujesz odpowiednie moduły.
0
dopiero się uczę C#, mógł byś napisać przykład jak to zrobić? :)
0
to jest zbyt obrzerny temat, zeby zrobi przykład. Umiesz korzystać z bazy z poziomu C#?
0
tak ;)
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using MySql.Data.MySqlClient;
using System.IO;
namespace PDN
{
public partial class Logowanie : Form
{
public Logowanie()
{
InitializeComponent();
}
public bool trylogin(string username, string pass)
{
FileInfo F = new FileInfo("config.dat");
StreamReader p = new StreamReader("config.dat");
string server = p.ReadLine();
string database = p.ReadLine();
string uid = p.ReadLine();
string password = p.ReadLine();
p.Close();
string mojePolaczenie =
"SERVER=" + server + ";" +
"DATABASE=" + database + ";" +
"UID=" + uid + ";" +
"PASSWORD=" + password + ";";
MySqlConnection con = new MySqlConnection(mojePolaczenie);
MySqlCommand cmd = new MySqlCommand("select * from test.per where user='" + username + "' and pass='" + pass + "';");
cmd.Connection = con;
con.Open();
MySqlDataReader reader = cmd.ExecuteReader();
if (reader.Read() != false)
{
if (reader.IsDBNull(0) == true)
{
cmd.Connection.Close();
reader.Dispose();
cmd.Dispose();
return false;
}
else
{
cmd.Connection.Close();
reader.Dispose();
cmd.Dispose();
return true;
}
}
else
{
return false;
}
}
private void LBT4_Click(object sender, EventArgs e) // przycisk zamykania okna logowania
{
Close();
}
private void LBT1_Click(object sender, EventArgs e) // przycisk logowania
{
if (trylogin(LTB1.Text,LTB2.Text) == true)
{
MessageBox.Show("Zalogowany");
this.Hide();
Konsola_Admina KA = new Konsola_Admina();
KA.ShowDialog();
}
else
{
MessageBox.Show("Złe dane");
}
}
private void LBT2_Click(object sender, EventArgs e) // przycisk opcji
{
this.Hide();
Opcje op = new Opcje();
op.ShowDialog();
}
public string mojePolaczenie { get; set; }
private void LBT3_Click(object sender, EventArgs e)
{
this.Hide();
Dod d = new Dod();
d.ShowDialog();
}
}
}
może mi ktoś doradzić JAK to zrobić w tym?
0
Przede wszystkim podziel sobie problem na kilka mniejszych.
0. Zadbać o strukturę kodu. Aktualnie jest byle jaki, bez żadnej konwencji czytanie tego to masakra. Napisałeś, że się dopiero uczysz ok, ale lepiej nabierać dobrych a nie złych nawyków.
Logikę działania aplikacji należy wynieść do osobnych klas, bo za chwilę będziesz miał 1k linii kodu i będziesz tylko scrollował.
- Zrobić logowanie użytkowników (na razie wygląda jakbyś miał tylko logowanie adminów),
- Zrobić odpowiednią strukturę w bazie:
2a. Każdy z użytkowników może mieć N przypisanych ról (np. Administrator).
2b. Każda z ról może mieć przypisanych N uprawnień (Np. Zakładka użytkownicy - Admin).
2c. (Opcjonalnie) Każde z uprawnień może odpowiadać za N operacji (np. pełny CRUD - czyli 4 operacje) - Sprawdzeniu czy w ogóle masz użytkownika w bazie sprawdzasz listę modułów/zakładek jakie powinieneś mu wczytać/uruchomić/odblokować. (Tu należy jakoś identyfikować zakładki/moduły/kontrolki w GUI).
0
sowa1993 napisał(a):
Witam, potrzebuje napisać logowanie do bazy danych. Ma ono sprawdzać login i hasło z bazy oraz pobierać poziom uprawnień jaki ma użytkownik (0-admin, 1-nauczyciel,2-uczeń). Jak ugryźć ten temat?** Potrafię napisać logowanie z loginem i hasłem**.
Do tabeli użytkowników dodaj pole "uprawnienia", dla każdego użytkownika uzupełnij odpowiednio 0, 1 albo 2. Pobieraj tak samo jak dotychczas, tylko wraz z polem "uprawnienia" (czyli jeśli teraz robisz np. select login, pass from users to daj select login, pass, rights from users).
0
Xiuthechutli napisał(a):
Przede wszystkim podziel sobie problem na kilka mniejszych.
0. Zadbać o strukturę kodu. Aktualnie jest byle jaki, bez żadnej konwencji czytanie tego to masakra. Napisałeś, że się dopiero uczysz ok, ale lepiej nabierać dobrych a nie złych nawyków.
Logikę działania aplikacji należy wynieść do osobnych klas, bo za chwilę będziesz miał 1k linii kodu i będziesz tylko scrollował.
- Zrobić logowanie użytkowników (na razie wygląda jakbyś miał tylko logowanie adminów),
- Zrobić odpowiednią strukturę w bazie:
2a. Każdy z użytkowników może mieć N przypisanych ról (np. Administrator).
2b. Każda z ról może mieć przypisanych N uprawnień (Np. Zakładka użytkownicy - Admin).
2c. (Opcjonalnie) Każde z uprawnień może odpowiadać za N operacji (np. pełny CRUD - czyli 4 operacje)- Sprawdzeniu czy w ogóle masz użytkownika w bazie sprawdzasz listę modułów/zakładek jakie powinieneś mu wczytać/uruchomić/odblokować. (Tu należy jakoś identyfikować zakładki/moduły/kontrolki w GUI).
ad 0. wiem że tutaj jest to wszystko wrzucone w jedno, ale nie wiem jak skonstruować te klasy żeby chodziły we wszystkich FORMach jakie mam.
ad 1. na razie jest logowanie zrobione na siłę do jednej formy nie zależnie od poziomu uprawnień.
ad 2a. Administrator będzie miał dostępne wszystko, potem coraz niżej.
ad 3. gdybym wiedział jak to zrobić to by było.
ad 4. dopisze sprawdzanie czy baza jest pusta. Jeżeli tak wyświetli mi się forma dodawania użytkowników, gdzie pierwszy użytkownik wpisany do bazy będzie miał zawsze prawa administracyjne (Administrator systemu).
1
Poszukaj w necie aspnet_Membership przeczytaj sobie jak on jest zbudowany po co są niektóre elementy i jak już skończysz (pewnie jutro albo w pojutrze) napisz swoje własne logowanie będące wycinkiem tamtego mechanizmu (z ewentualnie dodanymi od siebie elementami).
Co do poprzednich wypowiedzi to to które rozwiązanie wybierzesz jest decyzją architektoniczną:
- Możesz dodać 3 kolumny: IsTeacher, IsAdmin, IsStudent - rozwiązanie dobre jeżeli nie będzie więcej ról i mogą się zdarzyć przypadki że ktoś jest jednocześnie nauczycielem i adminem albo nauczycielem i uczniem (np. admin może dodawać nauczycieli ale nie będąc nauczycielem nie może wystawiać ocen). Rozwiązanie bardzo łatwe w implementacji ale może mieć wpływ na komplikacje logiki (o tych łączonych rolach łatwo zapomnieć).
- Dodajesz Tabelę Roles, a do użytkownika dodajesz kolumnę RoleId - użytkownik ma tylko jedną rolę, zaletą jest łatwiejsze dodawanie ról - dodajesz rekord bez zmiany struktury danych - u ciebie to nie robi różnicy jednak przy bazach z dużą ilością rekordów jest to problem, uprawnienia weryfikujesz po tym czy dany użytkownik ma rolę o znanym id/kodzie, to podejście wykorzystujesz gdy wiesz, że będą dochodzić nowe role a dodanie każdej z nich i tak będzie wymagało zmian w kodzie (może dojść sprzątaczka która, ma wgląd w swoje sprawy kadrowe ale nie ma możliwości sprawdzania danych klienta, albo sekretarka).
- Dodajesz tabele Roles i UserRoles - Jest połączeniem poprzednich dwóch - przy sprawdzaniu dostępu weryfikujesz czy pośród ról użytkownika jest ta której wymagasz, użytkownik może mieć wiele ról - tak jak w przypadku drugim pojawiają się nowe role ale wymagające zmian w kodzie.
- Dodajesz tabele Roles, Permissions, RolePermission - Każda rola ma listę swoich uprawnień, w kodzie weryfikujesz czy użytkownik posiada uprawnienie - nie interesują cię role. To czy użytkownik ma uprawnienie wynika z tego do której Roli jest przypisany, może też być przypisany do wielu Ról (wymaga to tabeli UserRoles). Częstą praktyką jest też dodanie tabeli UserPermissions pozwalającej dodać/zabrać uprawnienie konkretnemu użytkownikowi. To rozwiązanie stosuje się w systemach w których będą dochodzić nowe role ale będą one miały podzbiór funkcjonalności już istniejących ról, ewentualnie będą dodawać nowe - dodając rolę nie musisz łazić po kodzie żeby dopisywać ją do wszystkich metod tylko puszczasz skrypt dodający wpisy w bazie/ewentualnie klikasz w module. Rozwiązanie to się sprawdza też w przypadku gdy wdrażasz rozwiązanie w wielu organizacjach (na dużej uczelni może być więcej ról niż w małej szkole wiejskiej).
- Bardziej zaawansowane rozwiązania - do tabel autoryzacyjnych może dojść wiele, przykładem jest ww. mechanizm Membership który dokłada tabele Applicatation i Membership(którą można traktować jako UserApplications) pozwalające na jednej bazie trzymać uprawnienia dla wielu aplikacji, takie rozwiązanie sprawdza się gdy masz wiele systemów informatycznych w swojej firmie i chciałbyś żeby było jedno miejsce w którym da się odciąć użytkownika od wszystkich - nie znam aplikacji która rzeczywiście by korzystała z Membership i korzystała z takiej możliwości.
0
szogun1987 napisał(a):
Możesz dodać 3 kolumny: IsTeacher, IsAdmin, IsStudent - rozwiązanie dobre jeżeli nie będzie więcej ról i mogą się zdarzyć przypadki że ktoś jest jednocześnie nauczycielem i adminem albo nauczycielem i uczniem (np. admin może dodawać nauczycieli ale nie będąc nauczycielem nie może wystawiać ocen). Rozwiązanie bardzo łatwe w implementacji ale może mieć wpływ na komplikacje logiki (o tych łączonych rolach łatwo zapomnieć).
To rozwiązanie nigdy nie jest dobre, jego efektem są trzy kolumny w większości wypełnione nullami.
To samo można osiągnąć jedną kolumną typu całkowitoliczbowego. Przy założeniu, że np. Admin ma wartość 1, Student 2, a Teacher 4 bez problemu też obsłuży się przypadek, w którym student może być administratorem. Do tego, taką wartość łatwo zmapować na enum, więc obsługa po stronie kodu będzie dość wygodna.
Wadą jest to, że nazwy ról trzyma się wtedy w kodzie aplikacji, no ale w przypadku trzech kolumn bool też tak trzeba.
A bardziej zaawansowanego mechanizmu, z możliwością dodawania ról i uprawnień do każdej funkcji aplikacji przez użytkownika, autorowi chyba nie trzeba.
0
Po pierwsze nie nullami tylko 0 albo 1, po drugie obsługa maski bitowej zarówno w SQL-u jak i w C# jest mniej czytelna (zwłaszcza gdy nad programem siedzą początkujący programiści albo Hindusi). Pomimo że programuje już swoje znacznie bardziej odpowiada mi czytanie
if (user.IsAdmin)
niż
if (((RoleEnum)user.Role & RoleEnum.Admin) == RoleEnum.Admin)
owszem można zrobić wyliczane property ale po co? Skoro po dodaniu 3 kolumn Entity Framework nam je z automatu zmapuje na właściwości.
W SQL-u jest jeszcze gorzej ponieważ operacje bitowe olewają wszelakie indeksy i trzeba stosować ciąg orów, a to jest mało czytelne i generuje koszty związane z przejrzeniem wszystkich zapytań sql-owych w przypadku gdy dojdzie nam dodatkowa rola.
Moim zdaniem tych kilka bajtów na dysku nie jest warte takiej gimnastyki.
0
szogun1987 napisał(a):
Po pierwsze nie nullami tylko 0 albo 1
nulle zamiast zer po stronie sqla są trochę wygodniejsze
można chociażby napisać
SELECT
COUNT(IsAdmin) AS Liczba_adminow,
COUNT(IsStrudent) AS Liczba_studentow,
COUNT(IsTeacher) AS Liczba_nauczycieli
FROM tabela
w przypadku wartości 0 / 1 musisz się bawić w wolniejsze case'y
1
szogun1987 napisał(a):
if (((RoleEnum)user.Role & RoleEnum.Admin) == RoleEnum.Admin)
raczej:
if (user.Role.HasFlag(RoleEnum.Admin))
nic nie stoi na przeszkodzie żeby zrobić getter o nazwie IsAdmin który będzie zawierał ten kod
0
szogun1987 napisał(a):
Po pierwsze nie nullami tylko 0 albo 1, po drugie obsługa maski bitowej zarówno w SQL-u jak i w C# jest mniej czytelna (zwłaszcza gdy nad programem siedzą początkujący programiści albo Hindusi).
Piszmy wszystko w public static void Main, żeby było łatwiej dla początkujących. ;)
owszem można zrobić wyliczane property ale po co?
Po to, żeby trzymać się zasady DRY i pisać ekspresyjny kod. Właściwość IsAdmin jak najbardziej, ale to nie znaczy, że pod spodem musi to być zmapowane 1:1 do kolumny w tabeli. U mnie obiekty domeny zazwyczaj mają ze 2 razy więcej właściwości niż kolumn ma tabela, na którą są mapowane.
Skoro po dodaniu 3 kolumn Entity Framework nam je z automatu zmapuje na właściwości.
Serio dodana niedawno do EF obsługa code first to jakiś argument? Dla mnie to raczej dowód zacofania M$. ;)
W SQL-u jest jeszcze gorzej ponieważ operacje bitowe olewają wszelakie indeksy i trzeba stosować ciąg orów, a to jest mało czytelne i generuje koszty związane z przejrzeniem wszystkich zapytań sql-owych w przypadku gdy dojdzie nam dodatkowa rola.
Ok. Ale czemu chciałbyś to robić po stronie SQL? Przecież baza danych jest nieświadoma czegoś takiego jak uprawnienia użytkownika zalogowanego do aplikacji.
Moim zdaniem tych kilka bajtów na dysku nie jest warte takiej gimnastyki.
Tu nawet nie chodzi o kilka bajtów na dysku, lecz o łatwość rozbudowy o nowe role bez konieczności zmian w strukturze bazy.
0
Wkładanie do jednej kolumny rzeczy która powinna być w 3 jest komplikowaniem sobie życia na siłę. Praktycznie nic przez to nie zyskujemy (po za wspomnianymi kilkoma bajtami) a potencjalnie możemy dołożyć wiele roboczo-godzin, podczas diagnozy błędów czy analizy danych.
Po to, żeby trzymać się zasady DRY i pisać ekspresyjny kod. Właściwość IsAdmin jak najbardziej, ale to nie znaczy, że pod spodem musi to być zmapowane 1:1 do kolumny w tabeli. U mnie obiekty domeny zazwyczaj mają ze 2 razy więcej właściwości niż kolumn ma tabela, na którą są mapowane.
Właściwość wyliczana będzie fajna gdy mamy osobną tabelę z rolami (niezależenie czy w relacji 1:n czy n:n) i rzeczywiście tam nam zaoszczędzi nam powtarzalnego kodu. W przypadku gdy info o roli użytkownika znajduje się w wierszu nie widzę żadnej oszczędności ani duplikacji wynikającej z zapisu w jednej kolumnie a widzę koszty.
Serio dodana niedawno do EF obsługa code first to jakiś argument? Dla mnie to raczej dowód zacofania M$. ;)
Jest argumentem. Klepanie z palucha właściwości i kolumn to dopiero naruszenie DRY.
Ok. Ale czemu chciałbyś to robić po stronie SQL? Przecież baza danych jest nieświadoma czegoś takiego jak uprawnienia użytkownika zalogowanego do aplikacji.
Np. bo DB Nazi kazał mi coś wpakować w procedurę żeby się przez noc zdążyło wykręcić? Akurat wątpię żeby ten problem dotyczył tego systemu ale może się tak zdarzyć. poza tym dobrą praktyką jest aby wszelakie listy przeglądowe ładować przy pomocy procedur składowanych(ewentualnie z hurtowni danych które zasila się wynikiem złożonego zapytania SQL-owego).
Tu nawet nie chodzi o kilka bajtów na dysku, lecz o łatwość rozbudowy o nowe role bez konieczności zmian w strukturze bazy.
Na potrzeby coraz większej elastyczności podałem kolejne podejścia.
1
szogun1987 napisał(a):
Wkładanie do jednej kolumny rzeczy która powinna być w 3 jest komplikowaniem sobie życia na siłę. Praktycznie nic przez to nie zyskujemy (po za wspomnianymi kilkoma bajtami) a potencjalnie możemy dołożyć wiele roboczo-godzin, podczas diagnozy błędów czy analizy danych.
Poza bajtami zyskujemy możliwość dodawania nowych ról bez zmiany schematu. Jeśli ktoś potrafi coś spierniczyć przy wywoływaniu metody Enum.HasFlag, to lepiej żeby w ogóle się za programowanie nie brał. A wiele roboczogodzin podczas debugowania tracą tylko ci, którzy nie piszą testów.
Właściwość wyliczana będzie fajna gdy mamy osobną tabelę z rolami (niezależenie czy w relacji 1:n czy n:n)
Co to jest "relacja 1:n"? Bo na pewno nic związanego z bazami danych.
W przypadku gdy info o roli użytkownika znajduje się w wierszu nie widzę żadnej oszczędności ani duplikacji wynikającej z zapisu w jednej kolumnie a widzę koszty.
W każdym przypadku, nawet najprostszej operacji warto wydzielać duplikujący kod do metod/właściwości.
Jest argumentem. Klepanie z palucha właściwości i kolumn to dopiero naruszenie DRY.
Inne ORMy miały to już tysiąc lat temu, więc chwalenie się tym, że EF też to w końcu obsługuje jest dziwne.
Np. bo DB Nazi kazał mi coś wpakować w procedurę żeby się przez noc zdążyło wykręcić? Akurat wątpię żeby ten problem dotyczył tego systemu ale może się tak zdarzyć. poza tym dobrą praktyką jest aby wszelakie listy przeglądowe ładować przy pomocy procedur składowanych(ewentualnie z hurtowni danych które zasila się wynikiem złożonego zapytania SQL-owego).
Dzięki, ale nie pytałem o zastosowania procedur ani o dobre praktyki ich stosowania. Ja chciałbym wiedzieć, jaki związek mają procedury z systemem autoryzacji w aplikacji. Bo oczywiste jest podejście polegające na tym, że aplikacja dopuszcza użytkownika w danej roli do wykonania jakiejś akcji, a ta akcja wewnętrznie korzysta z procedury. Ale jak niby procedura ma sprawdzić, czy użytkownik aplikacji ma prawo do jej wykonania? jak do procedury przekazujesz kontekst zalogowanego użytkownika?
Na potrzeby coraz większej elastyczności podałem kolejne podejścia.
Które mają sens raczej w większych systemach, z dużo bardziej skomplikowanym przepływem sterowania. Mój pomysł to po prostu pewien kompromis prostoty i elastyczności. Nie nadaje się do każdej aplikacji, ale w wielu się sprawdzi. Myślę, że enum ma sens w każdej sytuacji, w której jest więcej niż jedna rola (bo dla jednej faktycznie wystarczy kolumna IsAdmin), i w której nie ma potrzeby, aby użytkownicy aplikacji mogli konfigurować uprawnienia do akcji. Jedna kolumna zawsze jest prostsza i wydajniejsza niż trzy tabele.
0
Poza bajtami zyskujemy możliwość dodawania nowych ról bez zmiany schematu. Jeśli ktoś potrafi coś spierniczyć przy wywoływaniu metody Enum.HasFlag, to lepiej żeby w ogóle się za programowanie nie brał. A wiele roboczogodzin podczas debugowania tracą tylko ci, którzy nie piszą testów.
Jeszcze więcej tracą ci którzy zaciemniają kod na siłę
Co to jest "relacja 1:n"? Bo na pewno nic związanego z bazami danych.
1:1 jest dla mnie relacją wykorzystywaną w niektórych systemach do modelowania dziedziczenia w której występuje primary foreign key. mówiąc 1:n zaznaczam że nie chodzi mi o tamto rozwiązanie
W każdym przypadku, nawet najprostszej operacji warto wydzielać duplikujący kod do metod/właściwości.
Te właściwości są bliskoznaczne ale nie jednoznaczne nie ma duplikacji
Inne ORMy miały to już tysiąc lat temu, więc chwalenie się tym, że EF też to w końcu obsługuje jest dziwne.
Odbiegasz od tematu. To nie jest wychwalanie EF tylko stwierdzenie że jedna bezsensowna kolumna utrudnia z niego korzystanie.
Dzięki, ale nie pytałem o zastosowania procedur ani o dobre praktyki ich stosowania. ... jak do procedury przekazujesz kontekst zalogowanego użytkownika?
Nie przekazuję ale mogę chcieć mieć raport zliczający pewne fakty w podziale na Role. W przypadku 3 kolumn zapytanie jest dużo czytelniejsze a często i wydajniejsze.
To rozwiązanie nie jest kompromisem, jest rzucaniem sobie klocków lego pod nogi, niby przejście po nich nie jest problemem nie jest jednak przyjemne.
0
Nie przekazuję ale mogę chcieć mieć raport zliczający pewne fakty w podziale na Role. W przypadku 3 kolumn zapytanie jest dużo czytelniejsze a często i wydajniejsze.
W przypadku jednej kolumny możemy skorzystać z GROUP BY i coś mi się wydaje, że zapytanie będzie jednak czytelniejsze w formie:
GROUP BY RoleId :)
0
szogun1987 napisał(a):
Jeszcze więcej tracą ci którzy zaciemniają kod na siłę
Pracowałem już przy kilku systemach, w których model ról był oparty na enumie po stronie aplikacji oraz jednej kolumnie w bazie, i nikt na to nie narzekał. Dla wszystkich był to prosty i oczywisty mechanizm, nikt nie narzekał, nikt nie postulował, żeby to rozbić na wiele kolumn. Bo 20, a nawet 10 dodatkowych kolumn Is* w tabeli to dopiero jest zaciemnienie.
1:1 jest dla mnie relacją wykorzystywaną w niektórych systemach do modelowania dziedziczenia w której występuje primary foreign key. mówiąc 1:n zaznaczam że nie chodzi mi o tamto rozwiązanie
Aha, czyli Ty też jesteś z tych, którzy nie wiedzą czym jest relacja. W porządku.
Odbiegasz od tematu. To nie jest wychwalanie EF tylko stwierdzenie że jedna bezsensowna kolumna utrudnia z niego korzystanie.
W żaden sposób nie utrudnia, nawet z EF. Właściwość mapuje się 1:1 z kolumną + ewentualnie dopisuje właściwości wyliczane.
Czy właściwość FullName, która jest konkatenacją FirstName i LastName też zapisujesz do bazy, bo łatwiej?
Nie przekazuję ale mogę chcieć mieć raport zliczający pewne fakty w podziale na Role. W przypadku 3 kolumn zapytanie jest dużo czytelniejsze a często i wydajniejsze.
Co prawda trudno mi sobie wyobrazić sensowny raport, na którym mogłyby się znaleźć dane z tak różnych ról, ale ok - to jest przypadek, w którym oddzielne kolumny będą lepsze.
To rozwiązanie nie jest kompromisem, jest rzucaniem sobie klocków lego pod nogi, niby przejście po nich nie jest problemem nie jest jednak przyjemne.
To, że czegoś nie lubisz stosować nie znaczy, że jest obiektywnie złe. To tylko Twoja osobista opinia.
0
Posiadanie 10-20 Is* oznacza przegapienie momentu w którym powinno się przejść na osobne tabele. Inna sprawa że idąc w ilość to twoja metoda się skończy na 31 (32 jak wejdziemy na liczby ujemne) roli podejście z Is* przy tysięcznej.
Aha, czyli Ty też jesteś z tych, którzy nie wiedzą czym jest relacja. W porządku.
To może mnie oświecisz?
0
szogun1987 napisał(a):
Posiadanie 10-20 Is* oznacza przegapienie momentu w którym powinno się przejść na osobne tabele. Inna sprawa że idąc w ilość to twoja metoda się skończy na 31 (32 jak wejdziemy na liczby ujemne) roli podejście z Is* przy tysięcznej.
Jeśli użyć biginta to nawet 64 a jeśli uniqueidentifier to i 128. :P No, ale to już jest oczywista przesada.
To może mnie oświecisz?
1:n, n:n, 1:1 to są powiązania, nie relacje. W relacyjnych bazach danych relacjami są tabele.