Willkommen bei Entwickler-Forum.
Seite 2 von 4 ErsteErste 1 2 3 4 LetzteLetzte
Ergebnis 11 bis 20 von 36
  1. #11
    Stammgast
    Registriert seit
    24.10.2011
    Beiträge
    1.282

    Standard

    1)
    ok

    2)
    ein Primärschlüssel garantiert eben keine fortlaufenden Zahlen, sondern nur eindeutige Werte(!, nicht mal Zahlen)
    (eigentlich nichts anders als eine spezielle Form Deines Unique für die Spalte 2)

    3)
    die fortlaufende Zahl per Select erzeugen: <Select max(id)+1 from mytable> *1 oder
    die Zahl in der Anwendung per Zähler verwalten und im Insert verwenden
    die fortlaufende Zahl per DB Code erzeugen oder
    die fortlaufende Zahl gar nicht mit abspeichern, sondern nur mit Ausgeben, wenn (ab)gefragt *2 oder

    oder
    oder

    4)
    weiß nicht, mglw. ist Access da anders als die Masse, ist es ja auch sonst an vielen Stellen. Allein deswegen würde ich aber niemals Access verwenden. Es gibt viele viele Alternativen.


    *1, normalerweise zu vermeiden, im singel user Betrieb wahrscheinlich ok,
    *2, nicht ganz gewöhnliches Vorgehen, kommt auf die sonstigen Anforderungen / Einsatz an, ob es taugt
    Gruß, defo

  2. #12
    Zaungast
    Registriert seit
    13.11.2016
    Beiträge
    25

    Standard

    Hallo Ralf,
    Zitat Zitat von Ralf Jansen Beitrag anzeigen
    Aber bitte nachher nicht über praktisch ungeeignete Motorsägen meckern
    So lange ich mir nicht die Hand dabei absäge, kann ich ja ein paar Experimente machen :-))
    Ich will mich etwas mit Datenbanken beschäftigen und auf die üblichen BWL-Aufgaben (welche Person verdient mehr als 1000 Euro und ist bei der Firma Makeall beschäftigt) habe ich keine Lust. Deswegen habe ich versucht eine mathematische Aufgabe umzusetzen (induktiv definierte Mengen, siehe unten).
    Kennst du DB-Aufgaben mit mathematischem Hintergrund ?

    Um wie viele Zahlenpaare geht es denn hier? Nicht mehr als maximal ein paar Zehntausend?
    Es geht um folgendes Problem:
    Nach dem "Urknall" gibt es die 2 Atome (Bausteine) 3 und 5
    3, 5
    Die folgende Regel R gibt an, wie aus einer Menge von Bausteinen eine neue Menge entsteht, die die alte Menge enthält:
    Addiere jeweils 2 Atome (die ungleich sein müssen, also nicht 2 gleiche Atome) aus der alten Menge und füge sie später der alten Menge hinzu.
    Beispiel:
    3,5
    Erweiterung1: 8 ergibt:
    3,5, 8
    Erweiterung2: 11, 13 ergibt:
    3,5, 8, 11, 13
    Erweiterung3: 14, 16, 19, 24, 18, 21 ergibt:
    3,5, 8, 11, 13, 14, 16, 19, 24, 18, 21
    ...
    Diese immens wachsenden Zahlen will ich in eine Tabelle einer DB schreiben.
    Wenn ich die Zahlen nicht durchnummeriere, muß ich jedes Mal mit SELECT alle Zahlen
    in eine Tabelle (Arbeitsspeicher) einlesen. Das ergibt ein schlechtes Laufzeitverhalten.
    (und wenn die DB immer größer wird, muß man immer mehr Zeilen einlesen - intern wird das ein Array o.ä. sein -
    das dann immer größer wird und durch die Größe des wobei Arbeitsspeichers beschränkt ist).
    Wenn ich die Zahlen dagegen durchnummeriere (so meine Idee) kann ich jedes Mal gezielt
    eine Zahl durch ihre Nummer in eine Variable einlesen (und nicht alle - was vermutlich nicht viel bringt, da ich ja auch alle Datensätze einlesen muß).
    Wie kommt man die Durchnummerierung hin ?
    Vor jedem Einfügen des Zahlenpaares (durch 2 Spalten realisiert) bestimme ich mit COUNT(*) in der SELCT Anweisung die Anzahl der Datensätze.
    Diese Zahl+1 ist dann die neue Nummer des einzufügenden Datensatzes.

    Dann denkt dir eine simple binäre Struktur deiner Zahlenpaare aus und schreib die komplett als Blob in die DB (Eine Zelle einer Tabelle).
    Lade dann immer komplett alle aus der DB und schreib die komplett wieder zurück. Es nützt nix nicht relationale Daten in eine relationale Struktur packen zu wollen.
    Das habe ich nicht ganz verstanden:
    Kann man in SQL nicht nur elementare Datentypen wie z.B. Integer in einer Spalte ablegen, sondern auch "selbstgebastelte" Datentypen wie z.B. ein Zahlenpaar oder eine noch komplizieret Struktur oder was hast du damit gemeint ?

    Um das klar zu sagen. Das gilt allgemein maximal in einer Singleuser Umgebung. In diesem merkwürdigen Problem hier ist das möglicherweise auch ok. Aber sich nicht üblicherweise.
    Ja klar, das Programm soll nur von genau einem Rechner mit genau einem Thread realisiert werden.


    mfg
    Bh

  3. #13
    Stammgast
    Registriert seit
    26.02.2003
    Beiträge
    4.824

    Standard

    Die Regel habe ich begriffen sehe aber keine sinnvolle Verwendung eine DB darin (Wir reden immer von Datenbank meine aber relationale Datenbank. Anders strukturierte Datenbanken könnten da hilfreicher sein).
    Ich könnte mir vorstellen das man da was nettes mit einer recusive Common Table Expressions machen kann. Das ist aber nix zum kennen lernen von Datenbanken sondern gehört in die Advanced Ecke.

    Kann man in SQL nicht nur elementare Datentypen wie z.B. Integer in einer Spalte ablegen, sondern auch "selbstgebastelte" Datentypen wie z.B. ein Zahlenpaar oder eine noch komplizieret Struktur oder was hast du damit gemeint ?
    Eigentlich jede DB unterstütz unspezifizierte Daten in einer Spalte abzulegen (meist BLOB genannt). Das heißt aber nicht das die Datenbank was genaueres über diesem Datentyp weiß. Es ist einfach ein Haufen Bytes.
    Die Datenbank kann nix anderes als die Daten ablegen und wieder rausrücken. Du kannst keine sinnvolle andere Methoden auf diese Daten anwenden. Wäre fast so als würdest du deine Daten einfach in ein File schreiben.
    Du hättest die Datenbank benutz ohne die Datenbank ~wirklich~ zu benutzen. Aber du hast ja auch kein ~wirkliches~Datenbank Problem zur Hand.


    Edit: Ich habe mal folgendes probiert.

    Code SQL:
    CREATE TABLE Atoms (Atom BIGINT NOT NULL);
    INSERT INTO Atoms(Atom) VALUES (3),(5);
    WHILE (10000 > (SELECT COUNT(*) FROM Atoms))
    BEGIN
      INSERT INTO Atoms 
      SELECT DISTINCT(a1.atom+a2.atom)
        FROM Atoms a1
               INNER JOIN Atoms a2 ON a1.atom != a2.atom 
     WHERE NOT EXISTS (SELECT atom FROM Atoms a3 WHERE a3.atom = (a1.atom + a2.atom))
    END

    Das wird aber schnell sehr langsam wenn man noch mehr Atome haben will (40000 Atome haben hier ~7 Minuten gebraucht)
    Beim ausprobieren hatte ich den Gedanken das das Beispiel auch wenn nicht passend für relationale Datenbank vielleicht doch ganz lehrreich ist. Kann es sein das du zu sehr algorithmisch über dein Problem nachdenkst? SQL im engeren Sinn beschreibt KEINE Algorithmen es beschreibt ein Ergebnis.

    Hat deine beschrieben Regel mit den Atomen einen Namen? Erscheint mir irgendwie merkwürdig denn man sollte ganz schnell immer alle natürliche Zahlen drin haben. Außer eben ein paar Lücken nahe den Startwerten.
    Geändert von Ralf Jansen (20.11.2016 um 15:21 Uhr)

  4. #14
    Stammgast
    Registriert seit
    23.04.2011
    Ort
    Zürich
    Beiträge
    435

    Standard

    Zitat Zitat von bernhart Beitrag anzeigen
    Hallo Ralf,

    So lange ich mir nicht die Hand dabei absäge, kann ich ja ein paar Experimente machen :-))
    Ich will mich etwas mit Datenbanken beschäftigen und auf die üblichen BWL-Aufgaben (welche Person verdient mehr als 1000 Euro und ist bei der Firma Makeall beschäftigt) habe ich keine Lust. Deswegen habe ich versucht eine mathematische Aufgabe umzusetzen
    Na dann fangen wir mal an und steigern uns. Hier in der Schweiz gab es von ein paar Jahre die Volksinitiative '1:12 - Für gerechte Löhne'. Diese Initiative verlangte, dass der höchste Lohn im Unternehmen maximal dem 12-fachen des niedrigsten Lohns sein darf.

    Aufgabe: Schreibe ein SELECT (oder UPDATE) Statement welches diese Forderung umsetzt für den Fall das die Volksinitiative an der Urne angenommen worden wäre.
    Es gibt natürlich mehrere Lösungen, entweder den Lohn des CEO kürzen oder die Löhne der niedrigen Einkommensstufen hoch setzen.

    Gruss

  5. #15
    Stammgast
    Registriert seit
    24.10.2011
    Beiträge
    1.282

    Standard

    Zitat Zitat von Wernfried Beitrag anzeigen
    Volksinitiative '1:12 - Für gerechte Löhne'. Diese Initiative verlangte, dass der höchste Lohn im Unternehmen maximal dem 12-fachen des niedrigsten Lohns sein darf.
    Sehr interessant, was ist draus geworden?
    Haben die Spitzenleute jetzt auch alle mehrere Jobs, liegt ja beim Fußvolk voll im Trend.
    Oder wird der Faktor 12 auf die Wochen/Monats/Jahresarbeitszeit berechnet?
    Und gibt es auch eine Volumenbetrachtung über die Anzahl der niedrig und hoch vergüteten Jobs in diesem Modell?
    Gruß, defo

  6. #16
    Stammgast
    Registriert seit
    23.04.2011
    Ort
    Zürich
    Beiträge
    435

    Standard

    Zitat Zitat von defo Beitrag anzeigen
    Sehr interessant, was ist draus geworden?
    Haben die Spitzenleute jetzt auch alle mehrere Jobs, liegt ja beim Fußvolk voll im Trend.
    Oder wird der Faktor 12 auf die Wochen/Monats/Jahresarbeitszeit berechnet?
    Und gibt es auch eine Volumenbetrachtung über die Anzahl der niedrig und hoch vergüteten Jobs in diesem Modell?
    Die Initiative wurde mit 65,3 % deutlich abgelehnt, so linke Forderungen haben in der Schweiz traditionell nur geringe Chancen. Der Vergleich Fussvolk = 40 Sunden/Woche Teppichetage = 60 Sunden/Woche war auch ein Thema. Falls du wirklich mehr über die Argumente dafür und dagegen wissen möchtest: Google ist dein Freund.

    Gruss

  7. #17
    Zaungast
    Registriert seit
    13.11.2016
    Beiträge
    25

    Standard

    Hallo Ralf
    1)
    Code SQL:
    CREATE TABLE Atoms (Atom BIGINT NOT NULL);
    INSERT INTO Atoms(Atom) VALUES (3),(5);
    WHILE (10000 > (SELECT COUNT(*) FROM Atoms))
    BEGIN
      INSERT INTO Atoms 
      SELECT DISTINCT(a1.atom+a2.atom)
        FROM Atoms a1
               INNER JOIN Atoms a2 ON a1.atom != a2.atom 
     WHERE NOT EXISTS (SELECT atom FROM Atoms a3 WHERE a3.atom = (a1.atom + a2.atom))
    END
    Das ist ja ein kleines Programm.
    Ich wußte nicht, daß SQL so mächtig ist.
    Weißt du, wie man diesen SQL -Befehl in C++ umsetzt ?

    2)
    Das wird aber schnell sehr langsam wenn man noch mehr Atome haben will (40000 Atome haben hier ~7 Minuten gebraucht)
    Meine einfachen SQL-Befehle in C++ umgesetzt brauchen schon bei ca. 500 Atomen ca. 10 Minuten.
    Vermutlich ist es besser While in den SQL-Befehl zu nehmen, als außerhalb in das C++ Programm.

    Beim ausprobieren hatte ich den Gedanken das das Beispiel auch wenn nicht passend für relationale Datenbank vielleicht doch ganz lehrreich ist. Kann es sein das du zu sehr algorithmisch über dein Problem nachdenkst?
    SQL im engeren Sinn beschreibt KEINE Algorithmen es beschreibt ein Ergebnis.
    Was meinst du mit "algorithmisch" nachdenken ?
    Das muß man doch beim Programmieren.

    Hat deine beschrieben Regel mit den Atomen einen Namen? Erscheint mir irgendwie merkwürdig denn man sollte ganz schnell immer alle natürliche Zahlen drin haben. Außer eben ein paar Lücken nahe den Startwerten.
    [/QUOTE]
    Habe dies Regel und die Anfangszahlen selbst gebastelt.
    Allerdings vermute ich, daß dies vor mir auch schon jemand gemacht hat.

    Ob die sich ergebende Zahlenreihe
    3, 5, 8, 11, 13, 14,16,17,18,19,20,21,22,23,24,25, ....348, ?, ?, ....
    irgendwann fortlaufend sich um 1 erhöht weiß ich nicht.
    Zumindest kommen 86 und 174 nicht mehr darin vor.
    Da du schon 40000 Atome produziert hast interessiert mich, ob darin irgendwann eine fortlaufende (sich um 1 erhöhende) Zahlenfolge drin vorkommt.
    (Kann man das mit einer SQL-Anweisung überprüfen?)

    mfg
    Bh

  8. #18
    Stammgast
    Registriert seit
    24.10.2011
    Beiträge
    1.282

    Standard

    Zunächst mal: Du hast irgendetwas falsch gequotet.

    Zitat Zitat von bernhart Beitrag anzeigen
    Hallo Ralf
    1)

    Das ist ja ein kleines Programm.
    Ich wußte nicht, daß SQL so mächtig ist.

    2)

    Was meinst du mit "algorithmisch" nachdenken ?
    Das muß man doch beim Programmieren.

    Da du schon 40000 Atome produziert hast interessiert mich, ob darin irgendwann eine fortlaufende (sich um 1 erhöhende) Zahlenfolge drin vorkommt.
    (Kann man das mit einer SQL-Anweisung überprüfen?)
    1) SQL ist sehr mächtig und man kann je nach dem, welche DB man nutzt auch Programmcode damit schreiben.
    Was Deine Experimente und MAthematik angeht. SQL ist am ehesten mit Mengenlehre zu vergleichen. Probleme oder Knobelaufgaben aus der Mengenleere sollten sich mit SQL also am einfachsten abbilden lassen.

    2) naja sein SQL Befehl ist ja nicht algorithmisch. Jedenfalls sind ein paar Zeilen SQL kein Algorithmus.

    3) man kann das Ergebnis mit SQL prüfen.
    Dazu muss die Ausgabe Deines Algorithmus mit einer Menge gejoint werden, die fortlaufend ist. Dabei kann der Join als Right Join gebaut werden und man kann dann an den Lücken sehen (field is null), wo Zahlen fehlen.
    Ca so:
    Code:
    select FeldMeineZahlen. FeldDurchGehendeZahlen
      from meineMenge 
           right join
           DurchgehendeMenge on
           FeldMeineZahlen = FeldDurchGehendeZahlen
     where MeineZahlen is null
    Gruß, defo

  9. #19
    Stammgast
    Registriert seit
    26.02.2003
    Beiträge
    4.824

    Standard

    Weißt du, wie man diesen SQL -Befehl in C++ umsetzt ?
    Nö. C++ benutze ich nur ganz selten. Ich habe andere Präferenzen.

    Was meinst du mit "algorithmisch" nachdenken ?
    Das muß man doch beim Programmieren.
    Ja aber SQL ist keine Programmiersprache im engeren Sinne. Du definierst mit SQL nicht wie die Datenbank Daten finden soll nur welchen Regeln das Ergebnis entsprechen soll. Die Datenbank entscheidet dann mehr oder weniger alleine welcher Weg am schnellsten zum gewünschten Ergebnis führt. Ich habe hier zwar algorithmische Sprachelemente benutzt (while Schleife) aber das ist eigentlich nicht Teil von SQL sondern eine reine Erweiterung. Der entscheidende Teil ist ja auch der Insert...Select und der ist kein Algorithmus.
    Um richtiges/gutes SQL zu erstellen muss man also gedanklich das Ziel beschreiben aber nicht den Weg dahin.

    Zumindest kommen 86 und 174 nicht mehr darin vor.
    Da du schon 40000 Atome produziert hast interessiert mich, ob darin irgendwann eine fortlaufende (sich um 1 erhöhende) Zahlenfolge drin vorkommt.
    Dann hast du dein Programm nicht lange genug laufen lassen Dort wo ich abgebrochen habe waren nachher alle natürlichen Zahlen > 15 enthalten. Ich denke das ist prinzipiell so das ab einer bestimmten Untergrenze (vermutlich direkt aus den Startwerten berechenbar) alle Zahlen im Ergebnis stecken für einen Beweis fehlen mir aber die Fähigkeiten (Einnschränkung wenn die Startwerte Primzahlen sind)

    Bei den Startwerten 3,11 scheint die Untergrenze 33 zu sein.
    Bei 7, 11 ist es 77.
    Bei 7, 13 ist es 104.
    Geändert von Ralf Jansen (21.11.2016 um 20:38 Uhr)

  10. #20
    Zaungast
    Registriert seit
    13.11.2016
    Beiträge
    25

    Standard

    Hallo Ralf,
    Danke für dein Feedback: mein Programm ist nicht lange genug gelaufen.
    Deswegen der Fehler.
    Dein Vorschlag war ja:
    ====================================
    CREATE TABLE Atoms (Atom BIGINT NOT NULL);
    INSERT INTO Atoms(Atom) VALUES (3),(5);
    WHILE (10000 > (SELECT COUNT(*) FROM Atoms))
    BEGIN
    INSERT INTO Atoms
    SELECT DISTINCT(a1.atom+a2.atom)
    FROM Atoms a1
    INNER JOIN Atoms a2 ON a1.atom != a2.atom
    WHERE NOT EXISTS (SELECT atom FROM Atoms a3 WHERE a3.atom = (a1.atom + a2.atom))
    END
    ====================================
    Bevor ich das in C++ umsetze, ist es vielleicht sinnvoll es direkt in SQL an eine DB Datenbank zu senden.
    Habe bis jetzt C++ verwendet und damit eine MS-Access DB erzeugt und angesprochen (weil sich MS-Access auf vielen Rechnern befindet).
    Frage:
    Weisst du, ob dein SQL-Befehl oben auch von MS-Access akkzeptiert wird ?

    mfg
    Bh

 

 
Seite 2 von 4 ErsteErste 1 2 3 4 LetzteLetzte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •