-----BEGIN PGP SIGNED MESSAGE----- Hello Adam,
Sunday, September 30, 2001, 2:56:52 AM, you wrote: > This makes it easy to build useless directories. OpenLDAP 2.x > (LDAPv3) directories must have schemas. This enforces structure as > you cannot put data in ad hoc. ACK. Else you could your filesystem... I think I'll dig into LDAP today as with I just figured out that some moron removed all functions that returned associative arrays from Python's MySQL interface on which my current code relied heavily (anyone ever tried to manage tables with >20 fields with only normal arrays) so I can basically throw the existing code away and start from scratch. AARGH. I've been thinking of using Python's wonderful pickle module (which serializes arbitrary classes automatically) to just create a customer class which in turn contains one or more account classes which then contain the individual data needed for the accounts and just store those few objects in a MySQL db...) as while I'm a big fan of OO, I honestly can't see much use for it in the current MySQL based approach to the server management stuff. > IMO a relational database is not best suited for what is > essentially just an address book. A directory is better suited. > LDAP is optimised for reads, since the operations in a directory > are mainly read. The nature of the data are not particularly > relational either (witness the simplicity of the RDB schema in the > SQL-based tools). > LDAP has built-in replication clustering, something that can be > taken advantage of with in qmail-ldap. MySQL got builtin replication too, but the clustering isn't very integrated right now. vpopmail goes great lengths to support clustered MySQL servers on its own, though. > The memory footprint of slapd 1.12.11 is <1MB on my FreeBSD box, > while mysqld weighs in at 25MB. Sure. But in most hosting environments, MySQL runs anyway cause the customers want it (and some of the admins, like me, use it heavily too). We too use FreeBSD, so you might be interested in a team effort to do a FreeBSD based server management tool for webhostering companies (cause that's what I try to achieve too, at the moment)? > that stores e-mail in a database. This seems to be a space > efficient manner to store e-mail that is cc:d to an entire > organisation, since only one copy of each e-mail need be stored. I > wouldn't advocate Depends. If the tool is sane, this saves lots of space but don't count on developers being sane enough to think of such features... > storing actual e-mail data in an LDAP store! However, I would be > reluctant to run my mail queue from a RDB. Wouldn't make too much sense anyway. I think there once was a project to feed all incoming mail from qmail directly into a MySQL DB but I couldn't really see much use for that. > Having said all that, I have not investigated the loading > characteristics of OpenLDAP 1 or 2. A poster to the qmail-ldap list > warned me off OpenLDAP 2, for example, because of instability under > load. > I was hoping to run everything under LDAP because I did not want to > run (and have to maintain) LDAP + some flavour of sqld. And the > data I am dealing with (user details, aliases, virtual domains and > members, etc.) are best suited to a directory. Depending on the amount of accounts per domain you want to handle, you might stick with cdb as an easy, no maintenance at all solution.... Best regards, Gabriel ÅÆ„†F„†F -----BEGIN PGP SIGNATURE----- Version: PGP 6.5i iQEVAwUBO7bsyMZa2WpymlDxAQEDKggAsUe0IMXqp+bv35TuxzC7c6KV7mvmuntH OO5VNFFX8qjoUVpSUnV59/rc6NnlrioB8U1XWuWlYzZGZTlXKrGq3/kQAp8a8Nai EjoYn6Cr0+w83X7n1Nh2RnQ3ctBp9aU0ET9v8Vtvc2PN6tg6sIoMRY2TdxK1NNF1 fmfhQ+VpTH6bTO8HmOFqVS2l9rrHT4J/Ug2uuwC+Tu0E/1/tjeVvZdOmimOr1m36 CX4Yvo8/dUsaMD2fj/hFMBsQLVfnyT+ocDiZ8pCTkUTsuXinWBgWf/Wk83M+92HK GAUS+F6FD2VMgjnwE0Q8FxeqBoLNslmgyPJwhimjFM8eO62dgmLDKw== =XeGm -----END PGP SIGNATURE-----
