Вопрос производительности SQL Insert

Question

У меня есть эта таблица телефонной книги SQL Server 2005:

username(PK) Serial(PK) contact_name  contact_adr      contact_email  contact_phone 
bob          1           Steve         12 abc street    steve@bb.com   1234          
bob          2           John          34 xyz street    john@bb.com    5345          
bob          3           Mark          98 ggs street    mark@bb.com    1234          
patrick      4           lily          77 fgs street    lily@bb.com    1234          
patrick      5           mily          76 fgs street    mily@bb.com    1234          
von          8           jim           6767 jsd way     jim@bb.com     4564          

Теперь вы можете видеть, что в телефонной книге хранятся все контакты одного пользователя вместе.Хранение таким способом имеет преимущества, которых я не могу избежать.

Мой вопрос: если у меня будет 100 миллионов записей в таблице для всех пользователей, будет ли моя будущая вставка в приведенную выше таблицу очень дорогой?

Поскольку SQL Engine необходимо найти фактическое место для ввода данных (я имею в виду, под каким именем пользователя)

Я проверил с 1 миллионом строк, я не вижу заметных проблем.

Я спрашиваю, есть ли у кого-нибудь этот опыт или предложения для меня?

Спасибо

Answer 1

Оптимальный подход для адресной книги - это хеш-таблица NOSQL.Там нет необходимости для индекса на ПК.Алгоритм возвращает «страницу», где находится строка, идентифицируемая PK.Адресная книга пользователя также сохраняется вместе с пользователем в виде денормализованного отношения.Вставка накладных расходов незначительна.Hashed-PK оптимизирован для вставки / извлечения, когда известен PK.Отлично подходит для систем OLTP.Теперь, если вы хотите сделать что-то вроде выяснения, кто кого знает, так что контакты данного пользователя должны быть связаны с контактами всех других пользователей, тогда у вас есть другая банка червей.Но простое приложение адресной книги, где контакты данного пользователя остаются «закрытыми» для этого пользователя, тогда система хешированного первичного ключа является превосходной.

Answer 2

Вы не можете принудительно хранить данные вместе. Вы повторно упорядочиваете Сериал после вставки? Как вы гарантируете, что данные «хранятся вместе»?

Если вы хотите поместить все эти данные в одну таблицу, то это действительно зависит от структуры вашего индекса. Чем больше индексов в таблице, тем больше обработки происходит при самой вставке. Поскольку пользовательские таблицы обычно подвергаются интенсивным запросам и редко вставляются (относительно), они обычно интенсивно индексируются, и в этом случае вставки могут выполняться медленно. Ответ, как и почти на каждый вопрос БД: «Это зависит».

Answer 3

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

Но!Производительность почти наверняка пострадает, если вы будете использовать индексы для этой таблицы и у вас будет много, много, много, много строк внутри нее.

Answer 4

Прежде всего, имя пользователя, похоже, не является первичным ключом для вашей таблицы.Возможно, вам придется использовать его в сочетании с другим полем, если вы хотите, чтобы оно работало.На этом этапе я бы предпочел использовать ваш serial столбец в качестве первичного ключа и иметь индекс username для ответа на запрос получить контакты Боба эффективно.становиться медленнее по мере роста вашего стола.Но я не думаю, что будет слишком медленно, чтобы избежать такого подхода.

Answer 5

Одним из первых принципов проектирования БД является отсутствие избыточности данных: дизайн таблицы БД не соответствует этому принципу, поскольку одни и те же данные повторяются много раз. Разумным решением было бы создание отдельной таблицы для пользователей, отдельной таблицы для контактов и таблицы отношений между пользователями и контактами.