Есть массив чисел. Он загружается из базы. ВСЕ числа в программе как-то меняются и потом сохраняется назад в базу.
Как эффективнее — ввести ключ и потом каждое значение по ключу перезаписывать или просто тупо при каждом сохранении все в базе очищать и заново просто ее заполнять?
> ввести ключ и потом каждое значение по ключу перезаписывать
при вставке будет проверка constraints (уникальность ключа и пр.) и пересчет индекса, что снизит скорость заполнения
> или просто тупо при каждом сохранении все в базе очищать и заново просто ее заполнять?
Удалить БД (или таблицу), а потом заполнить через bulk insert (или его аналог в той БД, что ты используешь) эффективнее.
Только для небольшой таблицы (массив чисел) выигрыш может быть несущественным.
M>при вставке будет проверка constraints (уникальность ключа и пр.) и пересчет индекса, что снизит скорость заполнения
M>Удалить БД (или таблицу), а потом заполнить через bulk insert (или его аналог в той БД, что ты используешь) эффективнее. M>Только для небольшой таблицы (массив чисел) выигрыш может быть несущественным.
Так смотря какой тип базы. Key-value, например, для того ведь и сделаны – обновлять по ключу. Так что то что выше верно для "обычных" реляционных ну и наверное NoSQL общепринятых.
Здравствуйте, Hоmunculus, Вы писали:
H>Есть массив чисел. Он загружается из базы. ВСЕ числа в программе как-то меняются и потом сохраняется назад в базу.
H>Как эффективнее — ввести ключ и потом каждое значение по ключу перезаписывать или просто тупо при каждом сохранении все в базе очищать и заново просто ее заполнять?
Встречные вопросы:
У чисел есть какой-то ключ (положение в массиве или что-то другое)? Их нужно искать по какому-то критерию? Ну, т.е. надо ли для каждого числа создавать отдельную запись в бд? Может можно обойтись блобом? А может и вовсе без бд?
_____________________
С уважением,
Stanislav V. Zudin
Просто массив чисел. Без всяких ключей. Надо с базой.
Просто массив — это все равно таблица? В таблице ключ обязателен? Или можно для одномерного массива вообще не таблицу? (Если что в массиве могут быть повторяющиеся числа, так что сделать сами числа ключами не прокатит)
Здравствуйте, Hоmunculus, Вы писали:
H>Просто массив чисел. Без всяких ключей. Надо с базой. H>Просто массив — это все равно таблица? В таблице ключ обязателен? Или можно для одномерного массива вообще не таблицу? (Если что в массиве могут быть повторяющиеся числа, так что сделать сами числа ключами не прокатит)
Если ты не собираешься делать какие-то манипуляции с отдельными числами — выбирать их по какому-то критерию, использовать при поиске других данных, строить зависимости от этих чисел, то дешевле будет положить весь массив в одно поле.
Грубо говоря, будет в СУБД таблица из одного столбца с единственной записью.
Как-то так (зависит от используемой субд):
CREATE TABLE MY_PRECIOUS_DATA (
MY_ARRAY_OF_SMTH text
)
Из неё вычитывается весь массив за один вызов.
И так же сохраняется.
Только СУБД в таком сценарии избыточна. Но коли на бд всё завязано, то почему бы и нет.
Использовали такое решение.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Hоmunculus, Вы писали:
P>>Таблица с одним столбцом и значениями: P>>1 ----- ?? P>>55 P>>1 ----- ?? P>>33 P>>22 ---- ? P>>22 ---- ? P>>не будет работать.
H>В смысле? Почему? Я сделал уже. Работает
Как оно, без дополнительного ключа, строки с одинаковыми значениями "различает"? Что за субд такая интересная?
P>Как оно, без дополнительного ключа, строки с одинаковыми значениями "различает"? Что за субд такая интересная?
Это же просто колонка (без требования на уникальность значений).
И таблица без primary key.
(БД строки конечно различает по каким-то своим внутренним rowid).
Здравствуйте, paucity, Вы писали:
P>Здравствуйте, Hоmunculus, Вы писали:
P>>>Таблица с одним столбцом и значениями: P>>>1 ----- ?? P>>>55 P>>>1 ----- ?? P>>>33 P>>>22 ---- ? P>>>22 ---- ? P>>>не будет работать.
H>>В смысле? Почему? Я сделал уже. Работает
P>Как оно, без дополнительного ключа, строки с одинаковыми значениями "различает"? Что за субд такая интересная?
Здравствуйте, m2user, Вы писали:
M>Это же просто колонка (без требования на уникальность значений).
Возможно запамятовал, но вроде было время, когда СУБД "требовали" уникальность строк в таблице без PK (независимо сколько колонок)
Сейчас в онлайн песочницах попробовал, да работает и в sqlite, и в "серьезных" субд
M>(БД строки конечно различает по каким-то своим внутренним rowid).
Здравствуйте, Hоmunculus, Вы писали:
H>В смысле? Почему? Я сделал уже. Работает
По вашему описанию непонятно, что именно должно работать.
В реляционной алгебре кортежи обязательно должны быть попарно различны (по чисто академическим причинам), и у них нет понятия "порядка".
В SQL используется немножко другая алгебра, поэтому требования иметь уникальный ключ в таблице нету.
Но обычно под термином "массив" имеется в виду упорядоченный набор неуникальных значений.
А в SQL без order by порядок записей ничем не гарантирован.
Если вас не пугает перспектива записать [1, 7, 1], а потом прочитать [1, 1, 7] — то, может быть, всё и "работает".
А если пугает — то "работает" всё только потому, что вы заложились на implementation specifics, которое может сломаться в любой момент без уведомления.
Если не секрет — зачем вам реляционка? Какие именно свойства РСУБД вам потребовались, которые не получилось обеспечить банальной сериализацией массива в обычный файл?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Hоmunculus, Вы писали:
H>Есть массив чисел. Он загружается из базы. ВСЕ числа в программе как-то меняются и потом сохраняется назад в базу.
H>Как эффективнее — ввести ключ и потом каждое значение по ключу перезаписывать или просто тупо при каждом сохранении все в базе очищать и заново просто ее заполнять?
0. Зависит от конкретной СУБД.
1. В среднем, перезапись по ключу немножко менее эффективна, чем truncate, а потом вставка балком (потому, что truncate не журналируется).
2. Delete без условия, а потом insert — в среднем немножко менее эффективно, чем серия update
3. Как уже подсказали, если прямо не терпится использовать именно СУБД (например, по соображениям атомарности изменений), лучше такой массив хранить в виде одного поля одной записи. И чем компактнее — тем лучше.
В частности, если числа у вас фиксированной разрядности (и endianness при чтении и записи гарантированно не меняется), то лучше хранить его в виде BLOB (а не в виде, скажем, строки разделённых запятыми десятичных представлений).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
