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

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

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

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

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

4
kev 30 Авг 2011 в 18:06

3 ответа

Лучший ответ

Прежде всего: +1 к ответу @Paul Sasik.

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

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

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

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

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

1
Paolo Falabella 30 Авг 2011 в 14:24

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

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

3
Paul Sasik 30 Авг 2011 в 14:56

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

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

1
Florin Ghita 30 Авг 2011 в 14:16