[priseffects]

#programowanie #sql #mysql

Co myślicie mireczki? Tabela ma zawierać userów do systemu logowania w appce mobilnej. Ilość rekordów będzie od kilkudziesięciu tysięcy do kilku milionów. Robię bazę pierwszy raz w życiu. Tabela userów będzie przeszukiwana tylko przy logowaniu i rejestracji. W sumie to też podczas działania całej appki, ale to już po ID usera.

CREATE TABLE users (
 sno int(110) NOT NULL AUTO_INCREMENT,
 unique_id varchar(23) NOT NULL,
 name varchar(50) NOT NULL,
 email varchar(50) NOT NULL,
 coins int(11) NOT NULL,
 device_id varchar(80) NOT NULL,
 daily_tickets int(2) NOT NULL,
 weekly_tickets int(1) NOT NULL,
 location varchar(100) NOT NULL,
 device_lang varchar(5) NOT NULL,
 rate_on int(1) NOT NULL,
 ip varchar(40) NOT NULL,
 device_name varchar (200) NOT NULL,
 last_logged datetime DEFAULT NULL,
 logged_times int(5) NOT NULL,
 gender int(1) NOT NULL,
 paid_gifts(5) DEFAULT NULL,
 last_time_paid varchar(100) DEFAULT NULL,
 last_time_gift varchar(200) DEFAULT NULL,
 top_offer_package_name varchar(1000) DEFAULT NULL,
 top_offer_active int(1) DEFAULT NULL,
 encrypted_password varchar(256) NOT NULL,
 salt varchar(10) NOT NULL,
 created_at datetime DEFAULT NULL,
 PRIMARY KEY (sno)
)

[r.....3]

@priseffects: Pomyśl o indeksach, serio

[i.....y]

@priseffects: burdel według mnie. Po to są postacie normalne żeby z nich korzystać. Klucze obce i te sprawy. Wszystko w jednym to nie jest dobry pomysł. Jako widok żeby sobie zagregować całość jako podgląd może już tak. Ale zasadniczo tak się nie robi bazy jak robisz :)

[priseffects]

@roszd23: to w zasadzie tylko dla id, loginu, maila, dla reszty spowoduje to rozrost bazy

[priseffects]

@indywidualny: nigdy nie robiłem bazy, a jest mi potrzebna w zasadzie na już ;) freelancera nie użyję też, bo bieda piszczy :P
dlatego muszę na szybko stworzyć coś sam, co wytrzyma obciążenie dużej ilości userów ;) mam czas do rana^^

[priseffects]

@indywidualny: http://www.wikihow.com/Create-a-Secure-Login-Script-in-PHP-and-MySQL

co myślisz o tym? lepsze niż moje?

[i.....y]

@priseffects: No też będzie działać. Tylko taki trochę śmietnik. Jak apka mobilna to później pewnie jakiś kursor otwarty będzie, trzeba będzie wyraznie pisać co wyciągasz, bo branie całości to strata pamięci. Więcej zabawy w samej apce jak nieznormalizowane dane. Jakby zrobić więcej tabel to później wygodnie jest tego po prostu używać. Czasem jakiś join żeby więcej danych wziąć, a tak normalnie to tylko to co na logikę należy do danej tabeli

[i.....y]

@priseffects: ano lepsze w sumie. Ja generalnie w mobilnej apce uzylbym po prostu Firebase Authentication i Firebase Realtime Database. Jest po prostu zajebiście szybko i wygodnie xD Nie ma co wymyślać koła na nowo. Ale się nie sugeruj za bardzo. Nie jestem jakiś kozak i wzór do naśladowania xD

[priseffects]

@indywidualny: firebase możesz użyć w jednym przypadku, nie planujesz kilku milionów userów, w appce, która będzie się w większości opierać na bazie danych ;)
później już płacisz jak za zboże, bo pewnie i drugi plan nie wystarczy

[biwalencik]

Ja tu widzę minimum 6 tabeli.

1. Users (id, name email, pass)
2. devices(id, device_lang )
3. coins()
4. transactions()
5. loggs ()
6. offers()

Rady:
1. Więcej relacji, mniej pchania wszystkiego do jednej tabeli.
2. Pozyskuj tylko te dane, których będziesz potrzebował
3. Unikaj funkcji po lewej stronie operatora

Z całego serca polecam poczytanie o Database normalization
https://en.wikipedia.org/wiki/Database_normalization

[K.....o]

Żeby nie było kucharek sześć, to tylko napomknę, że chuujowa struktura powoduje trwały uszczerbek na zdrowiu psychicznym późniejszych developerów ( ͡° ͜ʖ ͡°)