Производительность в SQL Mobile с одним большим столбцом, который не выбран

Question

У меня есть база данных SQL Mobile с одной таблицей. В нем есть несколько столбцов с полезными, часто запрашиваемыми данными и один столбец, в котором хранится относительно большая строка для каждой записи (1000+ символов), которая не запрашивается часто.

Представьте себе эту фальшивую схему, поле "lifeStory" большое.

table1
String firstName
String lastName
String address
String lifeStory

Репрезентативный запрос будет

SELECT firstName, lastName, address FROM table1 WHERE firstName = :p1

Кто-нибудь знает о каких-либо проблемах производительности, оставляющих этот большой, редко запрашиваемый столбец в этой таблице?

Answer 1

Используя библиотеки VS2005 (c #) и SQLServerCE, я могу вам сказать, что это влияет на производительность , но я не могу действительно ответить , почему. Кроме того, на самом деле это длина данных в этом столбец, который отрицательно влияет на производительность, а не сам столбец.

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

table1

c1 NVARCHAR (20)
c2 NVARCHAR (20)
c3 NVARCHAR (20)
c4 NVARCHAR (20) 
c5 NVARCHAR (4000) //maximum allowed and fully populated for testing purposes

Если вы запустите ...

select c1, c2, c3, c4 From table1

... это занимает примерно 1560 миллисекунд.

Если вы создаете две таблицы, вытаскиваете большой столбец (и, естественно, предоставляете внешний ключ для связи между ними) и запускаете один и тот же запрос для первой таблицы, это займет примерно 660 миллисекунд.

Наконец, другие тесты показали мне, что дело не в количестве столбцов, а в размере данных в каждой строке. то есть 5 столбцов, 2 символа в ширину == 2 столбца, 5 символов в ширину. Кроме того, обязательно запустите их на своем мобильном устройстве. Вы можете тестировать их по отдельности, но из-за значительно большей мощности на моем ПК я обнаружил, что разница во времени составляет 10-20 миллисекунд, а не 1000 миллисекунд, показанных выше.

Почему? Это всего лишь предположение, но ...

В мобильном мире СУБД просто не может быть одинаковой; это не корпоративная база данных. Под покровом пари, они все еще выполняют OLEDB "ищет".

В целом, в мобильном пространстве я научился проектировать мои БД не как наиболее «нормализованные», а скорее для поддержки наиболее частого варианта использования. Удачи!

Answer 2

Вы не должны замечать какие-либо потери производительности, если вы не пытаетесь фактически просматривать / запрашивать данные в этом поле.