Есть ли недостаток в создании и удалении слишком много таблиц на SQL Server - PullRequest
3 голосов
/ 30 августа 2011

Я хотел бы знать, есть ли свойственный недостаток в следующем способе использования базы данных ... Я хочу создать систему отчетности с веб-интерфейсом, посредством которой я запрашиваю базу данных для соответствующих данных и отправляюрезультаты запроса к новой таблице данных с помощью «SELECT INTO».Затем программа сделает запрос из этой таблицы, чтобы показать «страницу» отчета.Преимущество этого заключается в том, что если данных много, они могут быть представлены пользователю за один раз в виде страниц.Доступ к одной и той же таблице данных можно получить снова и снова, пока пользователь запрашивает разные страницы отчета.Когда веб-сеанс заканчивается, таблицы могут быть удалены.

Я готов программировать вокруг таких проблем, как отслеживание таблиц и обеспечение их удаления при необходимости.

У меня есть смутное беспокойство по поводу того, что в течение длительного периода времени сама база данных может иметь какие-либо проблемы с обслуживанием из-за того, что со временем было создано и удалено так много таблиц.Даже изо дня в день, скажем, возможно, 1000 таких таблиц создаются и удаляются.

Кто-нибудь видит какие-либо причины для беспокойства?

Спасибо за любые предложения / проблемы.

Ответы [ 3 ]

3 голосов
/ 30 августа 2011

Прежде чем приступить к реализации своего решения, рассмотрите возможность использования SSAS или просто SQL Server с хорошей моделью и правильно проиндексированными таблицами.SQL Server, IIS и операционная система выполняют операции кэширования, которые будет сложно выполнить.

Причиной для беспокойства является то, что вы пытаетесь написать код, который попытается превзойти SQL Server и IIS ... Этоклассический пример преждевременной оптимизации .Тысячи и тысячи часов программиста были потрачены на то, чтобы SQL Server и IIS были максимально быстрыми и эффективными, и вряд ли ваша стратегия получит лучшую производительность.

1 голос
/ 30 августа 2011

Прежде всего: +1 к ответу Пола Сасика.

Теперь, чтобы ответить на ваш вопрос (если вы все еще хотите придерживаться своего подхода). Возможные причины для беспокойства при использовании столбцов VARBINARY (MAX) ( из MSDN )

Если вы отбросите таблицу, содержащую столбец VARBINARY (MAX) с Атрибут FILESTREAM, любые данные, хранящиеся в файловой системе, не будут удален.

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

IF OBJECT_ID('mydb..##temp') IS NULL
-- create temp table and perform your query

Таким образом, у вас есть большая часть логики для выполнения ваших запросов и совместного управления временными таблицами, что должно сделать его более удобным для обслуживания. Кроме того, они созданы для того, чтобы их создавать и удалять, поэтому можно с уверенностью предположить, что SQL Server никак не повлияет на создание и удаление многих из них.

1 голос
/ 30 августа 2011

1000 в день не должно быть проблемой, если вы говорите о маленьких столах.

Я не знаю sql-сервера, но в Oracle у вас есть концепция временной таблицы ( небольшая статья и другая ). Данные, вставленные в этот тип таблицы, доступны только в текущем сеансе. По окончании сеанса данные «исчезают». В этом случае вам не нужно ничего бросать. Каждый пользователь вставляет в одну таблицу и его данные не видны другим. Преимущество: меньше обслуживания. Вы можете проверить, есть ли у вас что-то похожее на sql-сервер.

...