SQLite
 sql >> база данни >  >> RDS >> SQLite

Колко гъвкави/ограничителни са типовете колони на SQLite?

Типовете колони на SQLite са гъвкави (динамични), основно изглежда, че обслужват приемането/адаптирането на твърди типове колони, използвани от други системи за управление на бази данни.

Забележка! този Asnwer НЕ препоръчва използването на странни и прекрасни типове колони.

1) Всъщност можете да използвате почти всяко име за тип колона, но има някои ограничения.

2) Типът колона е втората стойност в дефиницията на колоната, напр. CREATE TABLE table (columnname columntype .....,....) , въпреки че може да бъде пропуснато умишлено или може би неволно Забележка виж 5a)

3) Първото ограничение е mycolumn INTEGER PRIMARY KEY или mycolumn INTEGER PRIMARY KEY AUTOINCREMENT е специален тип колона. Колоната е псевдоним за rowid който е уникален цифров идентификатор (AUTOINCREMENT налага правило, че вровидът трябва да бъде по-голямо от последния използван rowid за таблицата, напр. ако ред използва идентификатор (9223372036854775807), тогава всички последващи опити за добавяне на ред ще доведат до грешка в SQLITE FULL. ). Автоматично увеличаване на SQLite

4) Други ограничения са, че типът на колоната не трябва да обърква анализатора на SQLite. Например тип колона PRIMARY, TABLE, INDEX ще доведе до изключение на SQLite (синтактична грешка (код 1) ) напр. когато се използва тип колона INDEX, тогава:-

android.database.sqlite.SQLiteException: near "INDEX": syntax error (code 1):

се случва.

5) Типът колона не е задължителен, например CREATE TABLE mytable (...,PRIMARY_COL,.... в този случай PRAGMA TABLE_INFO(tablename) няма да показва тип, напр. (3-ти ред).

08-08 07:56:23.391 13097-13097/? D/TBL_INFO: Col=cid Value=8
08-08 07:56:23.391 13097-13097/? D/ TBLINFO: Col=name Value=PRIMARY_COL
08-08 07:56:23.391 13097-13097/? D/ TBLINFO: Col=type Value=
08-08 07:56:23.391 13097-13097/? D/ TBLINFO: Col=notnull Value=1
08-08 07:56:23.391 13097-13097/? D/ TBLINFO: Col=dflt_value Value=null
08-08 07:56:23.391 13097-13097/? D/ TBLINFO: Col=pk Value=0

5а) В някои случаи SQLite Parser ще прескочи до валидни КЛЮЧОВИ ДУМИ, напр. CREATE TABLE mytable (mycolumn NOT NULL,... води до NOT NULL се използва за обозначаване на NOT NULL колона и типа се приема като без тип (таблицата_информация по-горе всъщност е от такава употреба).

6) Типът не е ограничен до една дума, напр. VARYING CHARACTER(255) или THE BIG BAD WOLF може да се посочи като тип, както може да се види от този извлечение table_info :-

08-08 08:23:26.423 4799-4799/? D/   TBLINFO: Col=type Value=THE BIG BAD WOLF

Причината да се използват нестандартни типове колони в SQLite!

Накратко нямане Причината, както беше посочено в началото, изглежда, че гъвкавостта на типовете колони е основно да се погрижи за лесното адаптиране на SQL от други системи за управление на бази данни.

Самите типове колони имат малък ефект, тъй като данните ще се съхраняват според това, което SQLite определя като клас за съхранение, който ще се използва. С изключение на rowid (вижте 3) по-горе) всяка колона може да съдържа стойности от всякакъв тип.

С изключение на данните, съхранявани като Blob, които трябва да бъдат извлечени с помощта на cursor.getBlob и че cursor.getBlob не може да се използва за данни, които не се съхраняват като BLOB (getBlob не се проваля с данни, съхранени като TEXT), можете много да извличате данни (всички те да не са непременно полезни), като използвате някой от курсора cursor.get???? методи.

Ето няколко примера:-

За колона, където данните long myINT = 556677888; се добавя (чрез ContentValues, напр. cv1.put(columnanme,myINT) );

След това :-

08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes: Column=INTEGER_COL<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS INT >>556677888<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS LONG >>556677888<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS STRING >>556677888<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS DOUBLE >>5.56677888E8<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS FLOAT >>5.566779E8<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS SHORT >>15104<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:      Unable to handle with getBlob.

getShort не се връща към съхранената стойност, getBlob не може да получи съхранената стойност.

За Double myREAL = 213456789.4528791134567890109643534276; :-

08-08 09:19:03.658 13575-13575/mjt.soqanda D/ColTypes: Column=REAL_COL<<
08-08 09:19:03.658 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS INT >>213456789<<
08-08 09:19:03.658 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS LONG >>213456789<<
08-08 09:19:03.658 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS STRING >>2.13457e+08<<
08-08 09:19:03.658 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS DOUBLE >>2.134567894528791E8<<
08-08 09:19:03.658 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS FLOAT >>2.1345678E8<<
08-08 09:19:03.658 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS SHORT >>6037<<
08-08 09:19:03.658 13575-13575/mjt.soqanda D/ColTypes:      Unable to handle with getBlob.

За String myTEXT = "The Lazy Quick Brown Fox Jumped Over the Fence or something like that.";

08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes: Column=TEXT_COL<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS INT >>0<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS LONG >>0<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS STRING >>The Lazy Quick Brown Fox Jumped Over the Fence or something like that.<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS DOUBLE >>0.0<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS FLOAT >>0.0<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS SHORT >>0<<
08-08 09:19:03.657 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS BLOB >>[[email protected]<<

И ето един доста нелеп пример с тип колона my_char_is_not_a_char_but_an_int според PRAGMA TABLE_INFO :-

08-08 09:19:03.657 13575-13575/mjt.soqanda D/TBL_INFO: Col=cid Value=7
08-08 09:19:03.657 13575-13575/mjt.soqanda D/   TBLINFO: Col=name Value=my_char_is_not_a_char_but_an_int_COL
08-08 09:19:03.657 13575-13575/mjt.soqanda D/   TBLINFO: Col=type Value=my_char_is_not_a_char_but_an_int
08-08 09:19:03.657 13575-13575/mjt.soqanda D/   TBLINFO: Col=notnull Value=0
08-08 09:19:03.657 13575-13575/mjt.soqanda D/   TBLINFO: Col=dflt_value Value=null
08-08 09:19:03.657 13575-13575/mjt.soqanda D/   TBLINFO: Col=pk Value=0

Резултатите (съхранени съгласно „Двойно“ по-горе) са:-

08-08 09:19:03.659 13575-13575/mjt.soqanda D/ColTypes: Column=my_char_is_not_a_char_but_an_int_COL<<
08-08 09:19:03.659 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS INT >>213456789<<
08-08 09:19:03.659 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS LONG >>213456789<<
08-08 09:19:03.659 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS STRING >>2.13457e+08<<
08-08 09:19:03.659 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS DOUBLE >>2.134567894528791E8<<
08-08 09:19:03.659 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS FLOAT >>2.1345678E8<<
08-08 09:19:03.659 13575-13575/mjt.soqanda D/ColTypes:  VALUE AS SHORT >>6037<<
08-08 09:19:03.659 13575-13575/mjt.soqanda D/ColTypes:      Unable to handle with getBlob.

Горното се основава на следното:-Типове на данни в SQLite версия 3 SQLite Autoincrement PRAGMA изявления

Кодът беше тестван/изпълнен на емулирано устройство GenyMotion, работещо с API22, компилиран с минимална версия 14 и цел 26.




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Първи стъпки с пълнотекстово търсене на SQLite

  2. Как да създадете приложение за офлайн интернационализация:Използвайте база данни на Sqlite

  3. Uncaught TypeError не може да извика метода 'opendatabase' на приставката undefined-SQLite с cordova 3.5

  4. Експортирайте база данни SQLite в XML файл

  5. Избройте всички индекси в база данни на SQLite