Witam,
używam silnika SQLite i mam taką oto tabelkę:
CREATE TABLE tab (
id INTEGER PRIMARY KEY NOT NULL
);
Gdy nie podam wartości dla id lub gdy podam NULL to SQLite samo wstawia odpowiednią wartość:
INSERT INTO tab(id) VALUES(NULL);
Czy da się, jeśli tak to jak zrobić aby SQLite w żadnym wypadku nie wstawiał własnej wartości do id, gdy nie wpisuję tej wartości explicite?
PRIMARY KEY implikuje NOT NULL i UNIQUE. Może Ty po prostu nie chcesz żeby to był primary key?
mychal.szczygiel napisał(a)
PRIMARY KEY implikuje NOT NULL i UNIQUE. Może Ty po prostu nie chcesz żeby to był primary key?
Właściwie atrybut 'id' ma się odnosić do innej tabeli - ma być to klucz obcy. Jednak chciałbym aby był równocześnie kluczem głównym.
:D Wiesz co? Chyba będzie lepiej jak opiszesz swój problem od początku i skupisz się na tym co chcesz osiągnąć :P
mychal.szczygiel napisał(a)
:D Wiesz co? Chyba będzie lepiej jak opiszesz swój problem od początku i skupisz się na tym co chcesz osiągnąć :P
Ok, po pierwsze NOT NULL przy PRIMARY KEY ma znaczenie, przynajmniej w SQLite.
Chce stworzyć taką tabelę:
CREATE TABLE user_comment (
user_id INTEGER PRIMARY KEY NOT NULL,
note TEXT NOT NULL,
FOREIGN KEY(user_id) REFERENCES user(id)
)
W momencie wykonania:
INSERT INTO user_comment(note) VALUES('notatki');
SQLite wstawia mi automagicznie do 'user_id' wartość - w przypadku pustej tabeli wartość 1, w przypadku nie pustej kolejną wartość numeryczną. Chciałbym aby SQLite tego nie robił. ;) Czyli aby powyższe wykonanie polecenia INSERT powodowało zwrócenie błędu zamiast dodania wiersza do tabeli.
Z tego co pamiętam to w którymś SQLite był taki "ficzer", że jak dałeś user_id INTEGER PRIMARY KEY NOT NULL, to był automatycznie autoincrement. A jak dałeś user_id INT PRIMARY KEY NOT NULL to już nie :)
A nie możesz pola note przenieść do tabeli user?
Marcin.Miga napisał(a)
Z tego co pamiętam to w którymś SQLite był taki "ficzer", że jak dałeś user_id INTEGER PRIMARY KEY NOT NULL, to był automatycznie autoincrement. A jak dałeś user_id INT PRIMARY KEY NOT NULL to już nie :)
I dalej ten "ficzer" działa i nawet zastanawiałem się już wcześniej czy go nie zastosować. Jednak tu mam zastrzeżenie czy nie będzie to działało "wolniej" niż gdy zadeklaruję jako 'INTEGER'?
Rev napisał(a)
A nie możesz pola note przenieść do tabeli user?
Raczej nie, ponieważ z tego co słyszałem może to zaważyć na wydajności przy wyszukiwaniu w tabeli "user", jeśli wartości 'note' będą zawierać długie poematy. ;)
Raczej nie, ponieważ z tego co słyszałem może to zaważyć na wydajności przy wyszukiwaniu w tabeli "user", jeśli wartości 'note' będą zawierać długie poematy. ;)
A wtedy wymyślili indeksy.
Rev napisał(a)
Raczej nie, ponieważ z tego co słyszałem może to zaważyć na wydajności przy wyszukiwaniu w tabeli "user", jeśli wartości 'note' będą zawierać długie poematy. ;)
A wtedy wymyślili indeksy.
Zapomniałem napisać, że w przyszłości do tabeli "user_comment" planuję dodać minimum atrybut typu BLOB, do umieszczania zdjęć.
To jeszcze gorszy pomysł.
Ale w każdym razie, rozwiązanie problemu jest dosyć śmieszne. Dodaj DESC.
http://sqlite.org/lang_createtable.html#rowid
Rev napisał(a)
To jeszcze gorszy pomysł.
Rozumiem, że chodzi o dodanie atrybutu typu BLOB do tabeli "user_comment"? Równie dobrze, mógłbym napisać, że jesteś brzydki, pomimo tego, że nigdy Cię nie widziałem. Poproszę o argumenty dlaczego to jeszcze gorszy pomysł oraz jaki jest lepszy pomysł?
Rev napisał(a)
Ale w każdym razie, rozwiązanie problemu jest dosyć śmieszne. Dodaj
DESC.
http://sqlite.org/lang_createtable.html#rowid
Rozwiązanie problemu nie jest śmieszne, nawet nie nazwałbym tego rozwiązaniem tylko "obejściem" problemu, dlatego że deklaracja kolumny jako "INTEGER PRIMARY KEY DESC" zgodnie z przytoczoną dokumentacją SQLite powoduje dwie znaczące różnice(oprócz tego, że tym razem SQLite nie pozwoli na wstawienie wartości "domyślnej", o co mi chodziło, jednak nie chce aby odbywało się to kosztem wydajności) w porównaniu do "INTEGER PRIMARY KEY" :