2011-01-08 14 views
0

Ich entwerfe ein System zur Aufzeichnung und Aufzeichnung von täglichen Messdaten. Die Daten bestehen aus einer Kategoriekennung, dem Datum/Uhrzeit und den Messdaten (davon können bis zu 500 Stück als Float oder Int angegeben werden).
Die Kategorien werden als eine Baumstruktur visualisiert, in der Daten sowohl einem Knoten als auch einem Blatt zugeordnet sind.
Die Rohdaten kommen in als CSV in folgendem Format:Projektdaten von flacher Tabelle zu Adjazenzliste

1/6/2001 15:55, /Node1/Node2/Node3, 121, 34, 452, 651, 167 
1/6/2001 15:55, /Node1/Node2/Node3/LeafA, 12, 34, 45, 65, 67 
1/6/2001 15:55, /Node1/Node4/Node5/LeafB, 21, 32, 43, 54, 65 

ich mit Adjazenzliste bin die Planung (siehe Database Structure for Tree Data Structure) für die Baumstruktur. Ich plane auch, eine zweite Tabelle nur für die Messdaten und das Datum/die Zeit zu haben. Auf diese Weise kann die Baumstruktur, sobald sie zum ersten Mal erzeugt wurde, immer wieder von der Messdatentabelle referenziert werden. Eine kleine Adjazenzlisten-Tabelle macht das System viel lesbarer. In der folgenden Kategorietabelle wäre Name ein Knoten- oder Blattname (z. B. Node1 oder LeafA) und FullName wäre der gesamte Zweigpfad (z. B. Node1/Node2/Node3/LeafA). Ich bin mir nicht sicher, ob ich beides brauche, aber ich denke, sie werden sich als nützlich erweisen, damit ich den FullName bei Bedarf nicht neu erstellen muss.

CREATE TABLE [dbo].[Category](
    [CatId] [int] IDENTITY(1,1) NOT NULL, 
    [ParentCatId] [int] NULL, 
    [Name] [nvarchar](30) NOT NULL, 
    [FullName] [nvarchar](MAX) NOT NULL 
CONSTRAINT [PK_Category] PRIMARY KEY CLUSTERED 
(
    [CatId] ASC 
) ON [PRIMARY] 
) ON [PRIMARY] 
GO 
CREATE TABLE [dbo].[MeasurementData](
    [CatId] [int] NOT NULL, 
    [DateCollected] [datetime] NOT NULL, 
    [foo] [int] NOT NULL, 
    [bar] [float] NOT NULL, 
) ON [PRIMARY] 
GO 
ALTER TABLE [dbo].[MeasurementData] WITH CHECK ADD CONSTRAINT [FK_ MeasurementData _Category] FOREIGN KEY([CatId]) 
REFERENCES [dbo].[Category] ([CatId]) 
GO 
ALTER TABLE [dbo].[MeasurementData] CHECK CONSTRAINT [FK_ MeasurementData _Category] 
GO 

Um die Daten in das System zu laden, ich die Verwendung von BCP dachte die CSV in eine flache Tabelle (in SQL Server 2008) und dann projiziert den flachen Tisch auf die hierarchische Tabellenstruktur zu laden.
Q1: Sollte ich diese Projektion mit T-SQL oder C# versuchen (C# -App außerhalb von SQL Server)?
Q2: Hat jemand einen vorhandenen Algorithmus, um das richtige Blatt schnell zu finden (oder zu erstellen und zurückzugeben), wenn die Kategoriekennung oben angegeben wird?

FYI, ich bin auch dabei, meinen Kopf um die rekursive Abfragesyntax zu wickeln, die das WITH-Schlüsselwort gefolgt von einem allgemeinen Tabellenausdruck verwendet - wenn ich rekursive Programmierung machen muss.
https://stackoverflow.com/questions/tagged/common-table-expression
http://media.pragprog.com/titles/bksqla/trees.pdf

Vielen Dank im Voraus

Antwort

1

Ihre Tabellenstruktur ein wenig strittig sein kann.

Die von Ihnen bereitgestellten Beispieleingabedaten legen nahe, dass der gesamte Maßnahmensatz für die gesamte Knotenliste gilt. Wenn dies wahr ist, dann sind Sie besser dran Hashing die Knotenliste String, so etwas wie diese bekommen:

TABLE: Category 

HashId NodeList 
====== =================== 
289383 node1\node2\.... 
139829 node6\node7\....

Der Fremdschlüssel aus MeasurementData ist jetzt auf dem Hashid.

Dies beantwortet Ihr Q1: Generieren Sie den Hash in C# beim Übergeben der Daten und generieren Sie zwei Ausgabedateien, die BCP bereit für die Kategorie-Tabelle und die MeasurementData-Tabellen sind.

Da dies eine Art von Data Warehouse ist, haben Sie keine Angst, andere Kopien der Daten zu generieren, die für den Abruf mit anderen Methoden optimiert sind, also machen Sie eine zweite Darstellung der Kategorien in einer CategoryDetails-Tabelle so etwas wie dieses:

TABLE CategoryDetails 

HashId NodeName ParentNodeName 
====== ========= ================= 
289383 node1 
289383 node2  node1 
etc, etc,

was, wie Common Table Expressions zu verwenden, habe ich auch um sie herum etwas Mühe Einwickeln Kopf hatte, aber sobald ich es herausfinden ich einen Blog-Eintrag geschrieben: http://database-programmer.blogspot.com/2010/11/recursive-queries-with-common-table.html

Verwandte Themen