Вопрос ввода данных в SQL Server на основе шаблонов - PullRequest
0 голосов
/ 08 декабря 2008

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

Я пересматриваю проект базы данных приложения Windows Forms, которое переписываю для Интернета с использованием ASP.NET. Кроме того, я перенес нашу базу данных на Sql Server, чтобы он мог обрабатывать больше трафика, поскольку база данных Access уже перегружена. Итак, в результате того, что я понял, на что способен SQL Server, я пересмотрел свои решения по проектированию базы данных и их влияние на мой дизайн пользовательского интерфейса.

В настоящее время интерфейс Windows отображает список последних кодов:

02691 AFF1
32391 Lot# 23

и т. Д.

Для каждого кода в таблице Productions есть запись, которая начинается с:

ProductionCode varchar(80),
Template       varchar(50),
...

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

Существует таблица ScoreField, которая представляет все поля во всех шаблонах, кроме ProductionCode (который во всех них является внешним ключом).

ScoreField

Template       varchar(50)
Field          varchar(50)
Formatting     varchar(50)  // This is a .NET style formatting string, say 0.00 or ##
...

Затем есть сами таблицы шаблонов, которые содержат код производства, время для каждого теста и любые данные, собранные тестом.

Итак, чтобы создать свою сетку данных, я начинаю с

SELECT * FROM ProductionRun WHERE ProductionCode = @Code

На самом деле, я просто получаю один результат или прекращаю процесс, если не получаю никаких результатов.

Где код - это строка кода, выбранная пользователем (используя раскрывающийся список, а не что-либо уязвимое для инъекции)

Тогда я делаю:

SELECT * FROM ScoreField WHERE Template = @Template

Где @Template на самом деле, возвращено значение поля Template для одной записи ProductionRun.

Тогда я делаю:

SELECT * FROM @Template WHERE ProductionCode = @Code

Но на самом деле, я просто объединяю имя шаблона, полученное в первой части.

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

Но, конечно, в результате выполнения всего этого во время выполнения я не могу использовать привязку данных и вынужден программно заполнять все свои данные.

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

Очевидно, что это не простой вопрос программирования, а скорее вопрос лучших практик, но я искал вдохновение и / или примеры, чтобы начать меня другим путем.

Ответы [ 2 ]

1 голос
/ 08 декабря 2008

Учитывая ваш комментарий выше, я бы, вероятно, смоделировал это как ниже.

CREATE TABLE dbo.Products (
    product_code    VARCHAR(10) NOT NULL,
    product_name    VARCHAR(50) NOT NULL,
    CONSTRAINT PK_Products PRIMARY KEY CLUSTERED (product_code)
    )
GO
CREATE TABLE dbo.Measurement_Types (
    measurement_type_code           VARCHAR(10)     NOT NULL,
    measurement_type_description    VARCHAR(255)    NOT NULL,
    format                          VARCHAR(20)     NOT NULL,
    CONSTRAINT PK_Measurement_Types PRIMARY KEY CLUSTERED (measurement_type_code)
    )
GO
CREATE TABLE dbo.Measurements (
    product_code            VARCHAR(10)     NOT NULL,
    measurement_type_code   VARCHAR(10)     NOT NULL,
    measurement_value       DECIMAL(10, 4)  NOT NULL,
    CONSTRAINT PK_Measurements PRIMARY KEY CLUSTERED (product_code, measurement_type_code),
    CONSTRAINT FK_Measurements_Products FOREIGN KEY (product_code) REFERENCES dbo.Products (product_code),
    CONSTRAINT FK_Measurements_Measurement_Types FOREIGN KEY (measurement_type_code) REFERENCES dbo.Measurement_Types (measurement_type_code)
    )
GO

Если измерения являются историческими, добавьте столбец DATETIME. Кроме того, не зная специфики, типы данных могут измениться.

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

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

1 голос
/ 08 декабря 2008

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

Если вы получаете разные данные в разных форматах, то, вероятно, было бы плохой идеей пытаться объединить все это в один тип результата, чтобы использовать привязку данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...