Почему нельзя создать поля типов Boolean или Date в Sqlite через DBeaver или SqliteStudio?
Добрый день коллеги,
строю базу данных Sqlite программно через flask или django, делаю в таблицах поля типа Boolean или Date, всё отлично билдится, БД создаётся. Открываю БД при помощи менеджеров таких как DBeaver или SqliteStudio, в таблицах показывает поля данных типов. Пытаюсь создать через менеджер поле подобного типа, у меня его просто нет в списке.
От сюда вопрос, как так происходит, что поля программно можно создать и работать с ними на живой БД, а через менеджеры создать нельзя?
Создаешь скорее всего через какой-то пакет, а там универсальные типы данных. И если база не поддерживает, то создается поле с ближайщим к нужному типу. Так и тут
- для Boolean скорее всего INTEGER со значением 1 или 0
- для Date строка с датой-временем
А при получение данных ORM(или что там у тебя) преобразует данные в нужный формат.
То есть в SQLite нет типов данных Boolean & Date. Поэтому DBeaver или SqliteStudio не позволяют такие создать.
Я так и думал пока не открыл через драйвер Sqlite в менеджере и не увидел типы как я указал, если бы это были приколы ORM тогда я там увидел бы простейшие типы данных как вы и сказали, но нет типы именно те которые мной были указаны при создании) И здесь мне не понятно, если я нативно могу работать с этими типами данных, то почему я их не могу создать?
YepBro, Я вас прекрасно понимаю и документацию я читал и о типах данных я знаю, мне просто не понятно, если я через jdbc:sqlite в DBeaver или Sqlite studio вижу типы данных не свойственные этому виду БД, созданные мной через ORM, то значит они нативно работают в этой БД, но создать такие типы в этих менеджерах я не могу, хочу разобраться почему так, без иронии и сарказма!
2.2. Date and Time Datatype
SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:
TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.
Applications can choose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.
Ivan, выше ссылка на Stackoverflow. Там есть упоминание про декларирование типов данных с примером создания колонки типа Boolean. То есть можно объявлять свои типы, но надо понимать, что это только видимость, храниться все равно будет в тех типах, что доспустимы.
3.1. Determination Of Column Affinity
For tables not declared as STRICT, the affinity of a column is determined by the declared type of the column, according to the following rules in the order shown:
If the declared type contains the string "INT" then it is assigned INTEGER affinity.
If the declared type of the column contains any of the strings "CHAR", "CLOB", or "TEXT" then that column has TEXT affinity. Notice that the type VARCHAR contains the string "CHAR" and is thus assigned TEXT affinity.
If the declared type for a column contains the string "BLOB" or if no type is specified then the column has affinity BLOB.
If the declared type for a column contains any of the strings "REAL", "FLOA", or "DOUB" then the column has REAL affinity.
Otherwise, the affinity is NUMERIC.
Note that the order of the rules for determining column affinity is important. A column whose declared type is "CHARINT" will match both rules 1 and 2 but the first rule takes precedence and so the column affinity will be INTEGER.
YepBro, И здесь я вас понимаю, я создаю некую таблицу с несуществующими сущностями через некий сторонний инструмент, он мне их создает, но так чтобы было понятно только ему, почему тогда я через непосредственно драйвер БД вижу там не аналоги полей со схожими параметрами, а реально те типы которые были в них изначально мной при создании заложены?
Создавал Sqlalchemy Flask, просматриваю DBveaver.
Ivan, тут, похоже, дело в том, как SQLite хранит типы. Детально его не изучал, но из использования слова “affinity” в описании типов предполагаю, что для таблиц, не объявленных как strict (это важно и упоминается в цитате YepBro), в определении таблицы внутри самого SQLite тип хранится в том виде, в каком он был объявлен, а правила сродства (affinity) действуют как вывод типов и применяются на лету при определении фактических типов.
Можно предположить, что ваши таблицы созданы ORM не как strict. Если, например, попробовать создать копию таблицы в режиме strict, у колонок будут уже фактические типы (не знаю, поддерживается ли такой синтаксис в SQLite, не проверял):
create strict table strict_article as
select * from article
Могу, конечно, ошибаться, но это самое логичное объяснение.
Простой
