Firebird Embedded vs SQLite

← →
Johnmen © (2008-08-03 01:20) [80]

Вот интересно, почему, когда какой-нибудь дятел задаст бредовый вопрос, на него тут же ведутся?
Неужели наивность или ЧСВ так сильно развито? Не хотелось бы верить в это...

← →
Украинец (2008-08-03 01:49) [81]

> Johnmen © (03.08.08 01:20) [80]
>
> Вот интересно, почему, когда какой-нибудь дятел задаст бредовый
> вопрос, на него тут же ведутся?
> Неужели наивность или ЧСВ так сильно развито? Не хотелось
> бы верить в это...

Вы хотите сказать что FB - недосервер?

← →
Johnmen © (2008-08-03 02:06) [82]

> Украинец (03.08.08 01:49) [81]

Я хочу сказать, что хохлы - ...

← →
Пробегал2.... (2008-08-03 04:21) [83]

Johnmen © (03.08.08 1:20) [80]
Вот интересно, почему, когда какой-нибудь дятел задаст бредовый вопрос, на него тут же ведутся?

мне кажется тебе нужно расслабиться наконец, нельзя же так переживать то по пустякам ;)

← →
Пробежал... (2008-08-25 11:27) [84]

Товарищи, а вот мне интересно, поле типа: INTEGER PRIMARY KEY autoincrement - оно 64-битное или 32-битное?

Вроде как в документации написано, что оно строго 32-ух битное, но почему тогда функция: sqlite3_last_insert_rowid - возвращает 64-х битное значение?

Ведь объявленный INTEGER PRIMARY KEY по идее должен быть псевдонимом для системной колонки rowid и по идее его можно не вводить, лишь для совместимости с другими БД. Или получается что INTEGER PRIMARY KEY это 32-ух битное, а системный rowid это 64-битное? Как же они тогда могут быть алиасами?

http://www.sqlite.org/c3ref/last_insert_rowid.html
The rowid is always available as an undeclared column named ROWID, OID, or _ROWID_ as long as those names are not also used by explicitly declared columns. If the table has a column of type INTEGER PRIMARY KEY then that column is another alias for the rowid.

← →
Пробежал... (2008-08-25 12:22) [85]

ну и если пошла такая пьянка - интересно, с русскими символами оператор LIKE регистрозависимый или нет? напрямую про русский не нашел, говорят что регистрозависимый для раскладки latin... а для русской?

← →
Игорь Шевченко © (2008-08-25 12:27) [86]

бегуны недоделанные

← →
Пробежал... (2008-08-25 13:40) [87]

Жалко, что самому модератору приходится указывать на правилах... Но что поделать:

Запрещается: Хамство, оскорбления, переход на личности...

http://www.delphimaster.ru/forums.shtml

← →
Курдль (2008-08-25 14:04) [88]

> Firebird Embedded vs SQLite

Oracle XE!
И сравнивать не надо будет - мосх напрягать...

← →
Medbe}I{onok XML © (2008-08-25 14:14) [89]

канешна fb.
чем меньше экзотики в мире, тем лучше.

← →
Курдль (2008-08-25 14:18) [90]

> Medbe}I{onok XML © (25.08.08 14:14) [89]

Ах, до чего же забавный у Вас ник!
Как взглянешь на него и кажется, что лучше него только ник:

LEWOЬЬON

← →
ketmar © (2008-08-25 15:09) [91]

>[84] Пробежал... (2008-08-25 11:27:00)
>Как же они тогда могут быть алиасами?
а вот так. берут и конвертируют. в надежде, что винт закончится быстрее, чем uint32.

>[85] Пробежал... (2008-08-25 12:22:00)
>русскими символами оператор LIKE регистрозависимый или нет?
нет. делай свой, благо, это элементарно. я себе вообще нечёткие уникодные регулярки заместо него вмонтировал как-то. %-)

---
Understanding is not required. Only obedience.

← →
Пробежал... (2008-08-25 16:35) [92]

эээ... Я вот спросил регистрозависимый ли он, ты ответил - нет.
Ты имел в виду, что поиск LIKE регистраНЕзависимый?

А как элементарно? Перебором всех записей что ли? А по другому не понимаю как...

← →
ketmar © (2008-08-25 16:44) [93]

>[92] Пробежал… (2008-08-25 16:35:00)
это я криво выразился. я в том смысле, что вне ASCII-диапазона LIKE не работает как надо.

>А как элементарно? Перебором всех записей что ли? А по другому не понимаю как…
в SQLite можно регистрировать свои функции. собственно, LIKE именно при помощи этого механизма и зарегистрирован, это не примитив, жёстко прошитый в коде. обычная user function. не помню точно, как оно называется — найдёшь, думаю. или порой в сети мой CDM — там есть как раз такая работа с SQLite. я добавил регэкспы, регистронезависимое сравнение строк через AnsiCompareText() и что-то ещё через этот механизм.

по-сути добавляется новая функция, которую потом можно использовать в обычном SELECT.

где-то в глубине док автор как раз упоминает, что для начиональных символов и сложных извратов LIKE надо перекрывать своей реализацией.

---
Understanding is not required. Only obedience.

← →
Пробежал... (2008-08-25 17:13) [94]

Ну а какова реализация? Я даже не представляю интерфейса написания такой user function, кроме как предоставления двух строк: которая хранится в БД и по которой ищется.

И вызов данной user function для КАЖДОЙ записи... Ведь это медленно получится? очень?

← →
ketmar © (2008-08-25 17:16) [95]

>[94] Пробежал… (2008-08-25 17:13:00)
>Ну а какова реализация?
обычный callback.

>Ведь это медленно получится? очень?
а LIKE и есть очень медленная штука. именно потому в новых скулитах появился модуль полнотекстовой индексации и поиска.

---
All Your Base Are Belong to Us

← →
tesseract © (2008-08-25 21:29) [96]

> а LIKE и есть очень медленная штука.

Я только в кронос видел, как она шустро работает. В других базах используеться отдельная полу-внешняя приблуда. Такая есть в Postgress и MS SQL - только она места и проца жрёт - матерь божья.

← →
ketmar © (2008-08-26 07:43) [97]

>[96] tesseract © (2008-08-25 21:29:00)
в SQLite тоже что-то подобное напиляли не так давно. как работает — не в курсе, не жевал.

---
Understanding is not required. Only obedience.

← →
Пробежал... (2008-08-27 12:16) [98]

> а вот так. берут и конвертируют. в надежде, что винт закончится
> быстрее, чем uint32

то есть, PK все таки у них всепгда 32-ух битное целое?

← →
ketmar © (2008-08-27 17:14) [99]

>[98] Пробежал… (2008-08-27 12:16:00)
нет, внутри uint64. но раз ты описал автоинкремент как 32-битное, то тебе видней, наверное. не будет же скулит за тебя типы править, это беспредел.

---
Understanding is not required. Only obedience.

← →
Пробежал... (2008-08-27 18:06) [100]

> нет, внутри uint64. но раз ты описал автоинкремент как 32-
> битное, то тебе видней

где я описал как 32-ух битное целое?! Это как раз в статьях везде говорится, что в SQlite нет типов данных, кроме PRIMARY KEY INTEGER, которое является 32-ух битным числом...

← →
ketmar © (2008-08-27 18:44) [101]

>[100] Пробежал… (2008-08-27 18:06:00)
вот и описал — INTEGER.
а вообще — в новом есть. но хорошо замаскированые. rowid же всегда был 64 бита, и таковым его можно получить соотвтствующей функцией.

---
Do what thou wilt shall be the whole of the Law.

← →
Пробегал2.... (2008-08-28 00:17) [102]

ketmar © (27.08.08 18:44) [101]
вот и описал — INTEGER

ладно. А как мне его описать 64-ех битным?

Да, в таблицах SQLite по-умолчанию, есть PK. Но рекомендуют вводить явный PK для большей совместимости с другими типами БД.

Иного спосода ввести PK кроме как PRIMARY KEY INTEGER я не встречал. Но при этом пишется, что это 32-ух битный PK будет... Не понимаю.

Вводить явный PK как "ID PRIMARY KEY INTEGER", а для извлечения все равно использовать rowid?

← →
ketmar © (2008-08-28 00:54) [103]

>[102] Пробегал2…. (2008-08-28 00:17:00)
>Вводить явный PK как «ID PRIMARY KEY INTEGER», а для извлечения все равно
>использовать rowid?
а в чём проблема? так и делай. тебе не пофигу? не заводи вообще, у него алиас есть. вот и используй алиас.

алсо, раз ты всё равно пишешь со скулитом — наплюй на «совместимость» и не мучай руки.

---
Do what thou wilt shall be the whole of the Law.

← →
Пробегал2.... (2008-08-28 01:12) [104]

ketmar © (27.08.08 17:14) [99]
нет, внутри uint64

Все таки по ходу ты ошибся.

3.0 The Extended API Only the three core routines described in section 1.0 are required to use SQLite. But there are many other functions that provide useful interfaces. These extended routines are as follows: int sqlite_last_insert_rowid(sqlite*);

вроде как 32-ух битное. Нигде не вижу упоминания, что PK является 64-ех битным. Только в заголовочном файле под delphi который я где-то нашел функция описана как возвращающая 64-ех битное значение int64...
Кто ошибся все таки и где?

И как тогда объявить 64-ех битный PK?

>[104] Пробегал2…. (2008-08-28 01:12:00)
странно. помнится мне, что 64 бита было. сам в заголовках видел. дарагой %-), а у тебя часом не вторая версия скулита?

---
Do what thou wilt shall be the whole of the Law.

← →
Пробежал... (2008-08-28 10:50) [106]

> странно. помнится мне, что 64 бита было. сам в заголовках
> видел. дарагой

Ну да, вот что в заголовчных файлах у меня на D:

function SQLite3_LastInsertRowID(db: TSQLiteDB): int64; cdecl; external "sqlite3.dll" name "sqlite3_last_insert_rowid";

На сайте скулайта вот тоже нашел: http://www.sqlite.org/capi3ref.html#sqlite3_last_insert_rowid

Last Insert Rowid sqlite3_int64 sqlite3_last_insert_rowid(sqlite3*); Each entry in an SQLite table has a unique 64-bit signed integer key called the "rowid". The rowid is always available as an undeclared column named ROWID, OID, or _ROWID_ as long as those names are not also used by explicitly declared columns. If the table has a column of type INTEGER PRIMARY KEY then that column is another alias for the rowid.

то есть, видимо все таки 64-ех битное. Единственное, что не uint, как ты писал ;)

Но в русской документации везде написано, что INTEGER PRIMARY KEY это 32-ух битное. На сайте скулайта тоже это можно встретить.
Видимо, это все относится действительно ко второй и ниже версиям.

Один вопрос, если я создам ID INTEGER PRIMARY KEY, а извлекать буду с помощью sqlite3_column_int64 - все ок будет? Получится int64?

Или объявлять PK как ID INT PRIMARY KEY?

← →
Пробежал... (2008-08-28 11:41) [107]

И еще не могу найти инфу - при UPDATE можно как-то получись количество отфетченных записей?

Или конкретно - нужно при UPDATE по условию WHERE по PK узнать апдейтнулась запись или нет (то есть, есть ли запись с таким ID или нет).

← →
Пробежал... (2008-08-28 12:34) [108]

в общем, применил последнее средство - взял да и протестил ;)
Задавал поле ID INTEGER PRIMARY KEY, один хрен в него можно писать числа навроде "22222222223" и они нормально считываются...

← →
Пробежал... (2008-08-28 14:06) [109]

Странность обнаружена... Если делать новую запись, у которой ID (PK) равно уже существующей записи - то запись не добавляется в базу.
Но что странно, при этом не возникает никаких ошибок... Шозанафиг?

← →
Пробежал... (2008-08-28 14:13) [110]

ну и интересно имеет ли смысл в SQLite делать индексы.

>[106] Пробежал… (2008-08-28 10:50:00)
>в русской документации
не читайте перед обедом советских газет. (ц)

>Один вопрос, если я создам ID INTEGER PRIMARY KEY, а извлекать буду с помощью
>sqlite3_column_int64 — все ок будет? Получится int64?
по-идее, всё будет нормально. ибо P.K. — это алиас для rowid.

>нужно при UPDATE по условию WHERE по PK узнать апдейтнулась запись или нет
я честно делал сначала SELECT.

>Если делать новую запись, у которой ID (PK) равно уже существующей записи — то
>запись не добавляется в базу.
>Но что странно, при этом не возникает никаких ошибок
видимо, логика «не проверил? ССЗБ».

>имеет ли смысл в SQLite делать индексы.
да. ускоряет заметно. посмотри в код — если скулит может использовать индекс, он и генерирует в VM код для использования индекса, а не обычный перебор.

---
Understanding is not required. Only obedience.

← →
Пробежал... (2008-08-28 18:18) [112]

> видимо, логика «не проверил? ССЗБ».

это как так. Если я говорю, что нет ошибок - это значит что как раз проверил. Экспериментировал на SQLite database browser. Не вставляет запись, но пишет NO ERROR.

> да. ускоряет заметно.

PK думаю индексируется по-умолчанию?

>[112] Пробежал… (2008-08-28 18:18:00)
>это как так
я к тому, что если юзер не сделал SELECT, чтобы лично выяснить — то он ССЗБ, это скулит не заботит. %-)

>PK думаю индексируется по-умолчанию?
кажется, да. вроде что-то такое в исходниках было. да сам глянь, какой код VM генирурет, и всё. там есть команда, которая показывает код, емнип.

---
Do what thou wilt shall be the whole of the Law.

Firebird Embedded vs SQLite Найти похожие ветки