4. CREATE TABLE .. maximale Spaltenname Länge

CREATE TABLE .. maximale Spaltenname Länge

  • ?

    Hallo,

    über OleDB (in C#) erzeuge ich ein Excel Tabelle.. dabei erzeuge ich ein Sheet via Create table.. allerding bekomm ich immer eine exception, dasd die Spaltenname zu lang sind. Ich hab schon gegoogelt, aber keine Infos bekommen wie lang die Splatenname sein dürfen etc. Weis von euch jemand was?

    Oder kennt jemand ne (kostenlose) alternative daten in excel format zu speichern unter .NET bevorzugt c#^^

    0
  • P

    wie lange ist denn dein spaltenname?

    kannst dir auch ne cvs datei schreiben und diese mit excel öffnen oder so

    0
  • ?

    Der Spaltenname kann schon mal 200 Zeichen enthalten.. !!

    ja die CSV version hab ich als alternative.. aber excel wäre auch schön.

    0
  • N

    NullBockException schrieb:

    Der Spaltenname kann schon mal 200 Zeichen enthalten.. !!

    Wozu?

    0
  • ?

    Hierachische Model (Baum)... dabei setzt sich der Name der Blätter (Die nachher die Spalten ergeben) aus dren Parent Knoten zusammen;

    Root.Hallo.Welt.Ich.Bin.Eine.Spalte

    und diese String kann schon sehr sehr lang sein;)

    DESWEGEN;)

    0
  • N

    Das klingt nach einem völlig kaputten Design.

    0
  • -

    Wenn du noch ne Möglichkeit suchst, einen Baum effizient in einer DB zu speichern, schau mal hier: http://articles.sitepoint.com/article/hierarchical-data-database/2
    Verwaltung des Baums ist zwar komplexer als reine Vater->Kind Beziehungen, aber Abfrage wie "Alle Kinder von" sind super einfach und schnell...

    mfg
    xXx

    0
  • ?

    Es geht nich darum das ich ein Baum Model habe, oder das das Desing schlecht ist. Das Model agiert primär in einem total anderen Kontext. Es geht darum das Werte eines Knoten zu einem best. Zeitpunkt gespeichert werden.

    Die Eindeudigkeite eines Knoten ist nunmal über Namen der Väter und der Väters->Väter etc. bestimmt. Und diese Eindeudigkeit der Werte bzw. der eindeutigen Namen muss ich irgendwie als Spaltenname einsetzen.

    Es geht nich darum ein Baum-Objekt-Hierachie zu speichern.

    0
  • -

    und was spricht gegen 2 Spalten mit NodeName und Value?
    Ich glaube wenn du weitere Hilfe brauchst, musst du mal genau erklären was das alles soll... So können wir nur Raten und du sagst jedesmal "nö, geht nich".

    mfg
    xXx

    0
  • Z

    NullBockException schrieb:

    Es geht nich darum [...]das das Desing schlecht ist..

    da wär ich mir nicht so sicher

    generell muss ein Knoten nur seinen direkten Elternknoten kennen, um einen Baum eindeutig abbilden zu können. Allerdings ist es fraglich, ob diese Beziehungen gerade in einer Datenbank und nicht besser softwareseitig abgebildet werden sollten

    eine Möglichkeit wäre zum Beispiel die:

    DeineTabelle:
[u]id[/u] | Wert1.Parent | Wert1.Value | Wert2.Parent | Wert2.Value | Wert3.Parent | Wert3.Value | ...
---+--------------+-------------+--------------+-------------+--------------+-------------|
0  | NULL         | 1           | Wert1        | 2           | Wert2        | 3           |

    Vorteil: der Baum kann sich während der Laufzeit verändern
    Nachteil: die Anzahl der Knoten ist fest vorgegeben

    andere Möglichkeit:

    DeineKnoten:
[u]id[/u] | Node    | Parent
---+---------+--------
0  | Knoten1 | NULL
1  | Knoten2 | 0

DeineWerte:
[u]id[/u] | Node | Value
---+------+-------
0  | 0    | 3.14
1  | 1    | 2.72

    Vorteil: Beliebig viele Knoten
    Nachteil: Die Struktur steht fest, Knoten können also nicht einfach einem anderen Parent zugewiesen werden (es sei denn, es ist später unwichtig, welche Beziehungen zu Zeitpunkt x bestanden)

    0
Anmelden zum Antworten