Schrift
[thread]3622[/thread]

Wo bringt ihr die SQL-Abfragen unter?: Quellcode? Separates Modul? DB?

Leser: 2


<< |< 1 2 >| >> 14 Einträge, 2 Seiten
pktm
 2005-09-24 16:56
#33583 #33583
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Hallo!

Bisher habe ich immer meine SQL-Abfragen (den SQL-Code ansich, nicht die Ausführung mit prepare, execute usw.) direkt in den Quellcode geschrieben.
Macht hir das auch so oder bringt ihr eure SQL-Abfragen in einem extra Modul unter oder schriebt ihr sie direkt in die DB?

Neuerlich bin ich nochmal über ein Projekt gestolpert, das die Abfargen in ein Extra Modul gesteckt hat.

Wie machtihr das? Wieso? Vorteile & Nachteile?
http://www.intergastro-service.de (mein erstes CMS :) )
renee
 2005-09-24 17:02
#33584 #33584
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Ich schreibe die Statements in den Quellcode des Moduls, in dem auch die Datenbankabfragen gemacht werden...
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
Strat
 2005-09-24 19:48
#33585 #33585
User since
2003-08-04
5246 Artikel
ModeratorIn
[Homepage] [default_avatar]
ist bei mir sehr unterschiedlich, und haengt auch von der Art der Abfragen ab.

Ich habe recht haeufig ein Modul, das als Schnittstelle zur Datenbank dient. Haeufig steht mein SQL-Code in diesem Modul (bzw. wird hier generiert, wenn der Code dadurch flexibler wird; dann muss ich bei einer Migration auf eine andere Datenbank nur eine Datei kontrollieren und ev. anpassen).

Wenn allerdings diese SQL-Abfragen einfach veraenderbar oder von nicht-perl-programmierern einfach geaendert werden sollen koennen (z.B. bei einem Datensynchronisationstool), dann packe ich sie auch in ein eigenes Konfig-Modul oder sogar eine externe Config-Datei. Ich hatte sogar mal Bedarf fuer eigene SQL-Templates, die ich dann in externen Dateien abgelegt habe (das war bisher das einzige tempating system, das ich selbst geschrieben habe; heute wuerde ich HTML::Template oder so dafuer verwenden, aber das kannte ich damals noch nicht). Da wurde eine Datenbank on-the-fly so erstellt, wie ich sie fuer die zu importierenden Daten brauchte (abhaengig von den zu importierenden feldern)\n\n

<!--EDIT|Strat|1127576953-->
perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/
pq
 2005-09-26 00:02
#33586 #33586
User since
2003-08-04
12208 Artikel
Admin1
[Homepage]
user image
wenn eigenes sql, dann möglichst zentral in einem modul/einer
package-hierarchie und nirgendwo anders. das spart dir ne menge zeit,
falls du das db-schema änderst.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:Wie frage ich & perlintro Wiki:brian's Leitfaden für jedes Perl-Problem
format_c
 2005-09-26 01:36
#33587 #33587
User since
2003-08-04
1706 Artikel
HausmeisterIn
[Homepage] [default_avatar]
@pq: Wie sieht sowas denn genau aus?? Das wuerde mich jetzt auch mal interessieren.

Gruss Alex
pq
 2005-09-26 02:25
#33588 #33588
User since
2003-08-04
12208 Artikel
Admin1
[Homepage]
user image
@format_c:
naja, z.B. ein modul Module::StaticSQL, das alle manuellen db-abfragen
beinhaltet.
zuerst einmal würde ich dort an einer stelle die datenbank- und
tabellen-namen festlegen, etwa
Code: (dl )
1
2
3
4
5
6
7
8
my %db = (
 userdb => 'userdb',
 sessiondb => 'sessions'
);
my %tables = (
 userdata => 'userdata',
 items => 'items',
);

und dann methoden der einzelnen datenbank-queries.
Code: (dl )
1
2
3
4
5
6
7
8
9
10
sub update_userstatus {
 my ($self, $uid, $new_status) = @_;
 my $sql = <<"EOM";
UPDATE $db{userdb}.$tables{userdata}
SET status = ?
WHERE id = ?
EOM
 #execute
}
...

falls performance gefragt ist, kann man das auch mit konstanten für die
db/tabellennamen machen.
Code: (dl )
1
2
3
use constant DB_USER => 'userdb';
...
use constant TABLE_USERDATA => 'userdata';
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:Wie frage ich & perlintro Wiki:brian's Leitfaden für jedes Perl-Problem
format_c
 2005-09-26 11:25
#33589 #33589
User since
2003-08-04
1706 Artikel
HausmeisterIn
[Homepage] [default_avatar]
Also die SQL Daten hab ich sonst auch schon in Konstanten gepackt. Aber die SQL Abfragen bis jetzt noch nicht, da sie meist eh nur einmal pro Programablauf gebraucht werden. macht das da schon einen Unterschied?

Gruß Alex
Taulmarill
 2005-09-26 12:40
#33590 #33590
User since
2004-02-19
1750 Artikel
BenutzerIn

user image
man kann übrigens auch ganz auf SQL verzichten und module wie DBIx::Class oder Class::DBI verwenden.
$_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78
0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0
F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B
format_c
 2005-09-26 13:28
#33591 #33591
User since
2003-08-04
1706 Artikel
HausmeisterIn
[Homepage] [default_avatar]
Stimmt. Die müsste ich mir nochmal anschauen bei Gelegeheit. Hab beim letzten PM Stammtisch wo ich mal war nen Vortrag gehört.

Gruß Alex
renee
 2005-09-26 14:06
#33592 #33592
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Schau mal im Internet. Max müsste seinen Vortrag über CPAN:Class::DBI online haben. Irgendwo unter corion.net (http://corion.net/talks/index.html )
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
<< |< 1 2 >| >> 14 Einträge, 2 Seiten



View all threads created 2005-09-24 16:56.