Verständnisfrage zu sqlite3

[Schwarzer Wolf]

Ich Grüße Euch

Ich arbeite gerade an einem Programm, welches auch einen 'table' erstellen soll.

Nach dem Tutorial auf http://sebastianraschka.com/Articles/20 ... orial.html habe ich meinen Code folgendermaßen gemacht:

Code: Alles auswählen

    
    def table_create(self):
        """ create the table """

        # todo: output if create or failure

        table = self.table_name_input.get()
        one = self.language_one_input.get()
        two = self.language_two_input.get()

        conn = sqlite3.connect('./db/data.db')
        cur = conn.cursor()
        cur.execute('CREATE TABLE IF NOT EXISTS {table} ({one}, {two}, priority)'.format(table=table, one=one, two=two))

Sebastian rät nun unter 'Security and injection attacks':

Code: Alles auswählen

# 5) Check if a certain ID exists and print its column contents
c.execute("SELECT * FROM {tn} WHERE {idf}=?".\
        format(tn=table_name, cn=column_2, idf=id_column), (123456,))

Wenn ich aber nun z.B. "{one}=?" mache, kommt folgender Fehler:

Code: Alles auswählen

sqlite3.OperationalError: near "=": syntax error

Das Programm soll ausschließlich offline benutzt werden. Trotzdem möchte ich von Anfang an lernen, 'sqlite' sicher zu programmieren. Deshalb meine Frage:

Sind "nur" die 'queries' wie ('Select * FROM ...) von 'injection' bedroht oder auch das Anlegen eines 'tables'? Wenn auch das erstellen eines 'tables', wie kann ich es dann sicher machen?

[Sirius3]

@Schwarzer Wolf: man schreibt keine dynamischen Tabellen, wie es der Artikel macht. Datenbanken sind ein Teil des Programms, die fix sind, um Daten zu speichern. Der verlinkte Artikel ist in dem Punkt sehr schlecht, weil er suggeriert, dass man in SQL-Statements mit format arbeitet.

Du scheinst zusätzlich noch den Tabellennamen von einer Nutzereingabe abhängig zu machen, was nie Sinn macht, außer man will tatsächlich eine allgemeine Datenbankoberfläche schreiben, wo man aber schon sehr gute SQL und Pythonkenntnisse braucht.. Was willst Du eigentlich machen?

[__deets__]

Prinzipiell ist jede Art von statetement gefährdet. Und du hast auch bereits eine schöne SQL injection gebaut, da du Benutzereingaben direkt in ein Statement fließen lässt, mit String-formatting.

Ich würde ja grundsätzlich mal in frage stellen, welchen Sinn es hat ein Programm zu schreiben, welches Tabellen anlegt. Außer einem DB-Frontend ala pgadmin. Denn auf eine solche Tabelle kann ja kein anderer Code vorbereitet sein. Was willst du also eigentlich erreichen mit deinem Tool?

[Schwarzer Wolf]

@Schwarzer Wolf: man schreibt keine dynamischen Tabellen, wie es der Artikel macht. Datenbanken sind ein Teil des Programms, die fix sind, um Daten zu speichern. Der verlinkte Artikel ist in dem Punkt sehr schlecht, weil er suggeriert, dass man in SQL-Statements mit format arbeitet.

Du scheinst zusätzlich noch den Tabellennamen von einer Nutzereingabe abhängig zu machen, was nie Sinn macht, außer man will tatsächlich eine allgemeine Datenbankoberfläche schreiben, wo man aber schon sehr gute SQL und Pythonkenntnisse braucht.. Was willst Du eigentlich machen?

Ich bin dabei, eine Art Vokabeltrainer zu machen. Momentan ist noch alles in 'dicts'. Ich möchte in einem 'ttk.Notebook' eine Eingabe machen, die quasi Folgendes generiert:

1. Name (z.b. EnglishGerman)
2. Sprache 1 (z.b. English)
3. Sprache 2 (z.b. German)

Dazu wird eine Priorität festgelegt von 10, je öfter man das Wort per 'Multiple Choice' richtig hat, desto weniger wird der wert.

Es soll also mehrere unterschiedliche Sprachen angelegt werden können.

[__deets__]

Das erfordert aber keine dynamischen Tabellen. Eine Tabelle mit vier Spalten genügt im Grunde: (Sprache1, Wort1, Sprache2, Wort2) - das war's.

Daraus kann man dann eigentlich schon alles ableiten. Wenn man möchte, kann man natürlich etwas weiter ausholen & eine Tabelle mit (Id, Sprache) machen, eine Worttabelle mit (Id, Sprach_id, Wort) und eine Übersetzung mit (Wort_id1, Wort_id2). Womit man zB auch ein Wort in verschiedene Sprachen übersetzen kann.

[Schwarzer Wolf]

Das erfordert aber keine dynamischen Tabellen. Eine Tabelle mit vier Spalten genügt im Grunde: (Sprache1, Wort1, Sprache2, Wort2) - das war's.

Daraus kann man dann eigentlich schon alles ableiten. Wenn man möchte, kann man natürlich etwas weiter ausholen & eine Tabelle mit (Id, Sprache) machen, eine Worttabelle mit (Id, Sprach_id, Wort) und eine Übersetzung mit (Wort_id1, Wort_id2). Womit man zB auch ein Wort in verschiedene Sprachen übersetzen kann.

Wunderbar danke. Mal wieder zu komplex gedacht. Wenn ich nun erst mal die erste Lösung (Sprache1, Wort1, Sprache2, Wort2) mache, ist es dann schwer, später auf Dein anderes Konzept aus dem 2. Absatz zu gehen?

[__deets__]

Definiere schwer. Die DB ist dabei da sie geringste Problem, das ist mit einem kleinen Konvertier-Skript flux gemacht. Aber wenn die Logik nicht in ein Modell gegossen ist, so dass die GUI überall auf den Tabellen rumröhrt - dann wirds schwieriger.