(DB/SQL) Ориентированный на производительность способ управления данными координат карты

Question

У меня есть функция, которая позволяет пользователям создавать новое пятно/маркер на карте, используя обычное значение Latitude & Longitude или изменять любые существующие точки. И, очевидно, эти места нужно будет сохранить в таблице.

Сценарий: В настоящее время таблица содержит шесть наборов координат, которые изначально извлекаются на карту. Скажем, два из существующих пятен изменены, три из них удалены, и, наконец, к карте добавлены четыре новых пятна.

Теперь, будучи начинающим пользователем SQL, я мог думать только два подхода для написания Результирующих координат в базу данных следующим образом:

1. Удалить все существующие данные в таблице, а затем захватить все, что есть оставляются на карте и проходят через них и просто создают каждый набор координат.
2. Обновите данные для измененных мест. Удалите только те, которые фактически удалены пользователем. Создайте новые записи для всех новых мест.

Для этого упрощенного сценария я бы подумал, что для опции № 1 требуется один запрос DELETE и шесть запросов CREATE, в результате чего получается семь запросов, которые необходимо выполнить. С другой стороны, для опции № 2 требуются три запроса DELETE, два запроса UPDATE и четыре запроса CREATE, что составляет в общей сложности девять запросов.

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

Answer 1

1. Не будет осуществимо, если вы увеличите масштаб. Что делать, если клиент А изменяет 3 балла, а ваша таблица содержит 3 триллиона очков? Вы обрезаете всю таблицу, а затем вставьте все 2,9 триллиона очков? Если у вас был клиент B, который хочет просмотреть карту в течение этого времени, им придется подождать некоторое время, чтобы таблица вернулась. Кроме того, существует гораздо более высокий риск, когда вы говорите об обтирании стола.

2. Более традиционный, безопасный и простой в масштабировании.

Вы можете проверить оба из них легко с тестовыми данными, и вы будете иметь возможность наблюдать разницу

Примечание: Это не количество запросов, которое определяет производительность. Это то, что пытаются выполнить эти запросы, для чего предназначена ваша схема, и какую СУБД вы используете. Также взгляните на R-деревья. Они очень важны для эффективных пространственных запросов. http://en.wikipedia.org/wiki/R-tree

Answer 2

Хорошо, если вы используете какой-либо кластерный индекс, удаление многих элементов с помощью (1) может привести к фрагментации. вы также можете приблизиться к настройке «fill factor» вашего кластерного индекса, в зависимости от количества новых записей, которые вы ожидаете, чтобы было достаточно «бесплатных слотов». ваша база данных должна быть достаточно быстрой.