Лучший способ сделать 10000 вставок в базу данных SQL?

Question

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

Если бы на моем сайте было 10 000 человек, как бы я добавил его в очередь сообщений каждого человека? Я могу себе представить, что это занимает много времени, поэтому я бы выбрал что-то вроде журнала файловой системы? Отметьте, что мне нужно уведомить людей, данные, а затем мою текущую позицию. Затем обновлять мою позицию каждые 100 вставок или около того? Мне нужен ПК в моем списке наблюдателей, поэтому, если кто-нибудь зарегистрируется в середине этого списка, мой заказ не будет нарушен, так как я буду сортировать по PK?

Это лучшее решение для системы массовых уведомлений?

-edit-

Этот сайт является сайтом, созданным пользователем. Администраторы могут отправлять глобальные сообщения, а популярные люди могут иметь тысячи подписчиков.

Answer 1

Если 10000 вставляет в узкую таблицу «многие ко многим», связывающую получателей с сообщениями (recipientid, messageid, status) медленно, я ожидаю, что у вас больше проблем с вашим дизайном.

Это та операция, которую я обычно не беспокоюсь о пакетировании или подписке людей в середине почтовой операции - в основном:

Предполагая, @publisherid известно, @msg известно на SQL Server:

BEGIN TRANSACTION

INSERT INTO msgs (publisherid, msg)
VALUES(@publisherid, @msg)
SET @messageid = SCOPE_IDENTITY()

INSERT INTO msqqueue (recipientid, messageid, status)
SELECT subscriberid, @messageid, 0 -- unread
FROM subscribers
WHERE subscribers.publisherid = @publisherid

COMMIT TRANSACTION

Answer 2

Я бы сказал, просто позвольте базе данных позаботиться о том, на что она способна и на что способна. Вставьте и управляйте данными. Не пытайтесь делать это в коде, просто напишите SQL, чтобы вставить данные за один раз. 10000 строк - пустая трата времени для всех реальных баз данных.

Answer 3

Может быть, просто запишите для каждого пользователя, какие уведомления они видели, так что набор уведомлений, которые должны быть показаны пользователю, создан до горизонта "ранее" (когда они зарегистрированы, или неделю назад ...) минус те они признали. Таким образом вы откладываете вставку чего-либо до тех пор, пока он не станет единственным пользователем сразу, плюс, если вы показываете пользователям только сообщения, которым меньше недели, вы можете очистить флаги чтения-этого-уведомления, которые устарели неделей или старше.

(совет по оптимизации Peformance от моего администратора баз данных на моей старой работе: «бизнес-процессы - это самое легкое, что нужно изменить, посмотри на них сначала»)

Answer 4

Если вы используете Postgres, вы можете использовать команду COPY, которая является самым быстрым методом из всех:

COPY tablename (col1, col2, col3) FROM '/path/to/tabfile';

, где tabfile - это файл с разделением табуляции и множеством записей. Это не удастся, если есть некоторые УНИКАЛЬНЫЕ ограничения, и есть дубликаты в файле.

Answer 5

ИМХО вставка записей может быть не самым эффективным решением этой проблемы. Можете ли вы использовать файл cookie на стороне клиента для хранения того, удалил ли пользователь уведомление или нужно отслеживать его, даже если они удаляют файлы cookie? Если вы загружаете новое видео, приложение может просто сравнить файл cookie с новым идентификатором видеозаписи и принять решение показать или скрыть уведомление на основе того, что хранится в файле cookie. Это сэкономит вам массу вставок в базу данных и сохранит большую нагрузку на клиента.