Multiple database usage in same Links SQL? - Suggestion
Multiple database usage within the same Links SQL was discussed several times in the forums, but I did not find clear opinion of Alex, if the developers would like to implement this...
Let me show you, what features I mean by the "Multiple database usage":
create new "links databases" from admin interface
a new "links database" can be created 2 optional ways:
each "links database" has its own config files & tables as showed above
having a downdrop menu at the top-left of admin screen to select the actual "links database" we are working on
the dynamic page display scripts like page.cgi should have posted a "db" argument in the url like this:
E.g:
http://www.site.com/cgi-bin/page.cgi?g=Computers/Video&db=faq
or
http://www.site.com/cgi-bin/page.cgi?g=Computers/Video&db=news
Reasons, why the "Multiple database usage" feature would be fine:
separate backupability of the "links databases".
Just imagine that a faq database does not need so frequent backups like a links or news database. So if you have faq, news & links, then it's logical to store them in separate "links databases" not in just one.
speed & efficiency: having these databases separately the speed can be increase if e.g: both links & news is a big database.
A website having several services with high traffic using dynamic page display, may slow down because of locks. Using separate tables or databases, much higher traffic is possible per service.
more safety(?)
Well, in overall, there are quite a few places where the "multiple database" feature needs modification, but I think it's not a very difficult job. However requires many similar modifications across many dynamic cgi files, some in the admin interface, and maybe some in a few other .pm files.
Modifications required:
modifications in admin.cgi and some files which is used by admin interface
modifications in page.cgi, add.cgi, jump.cgi, etc... dynamic pages to treat the "db" argument
Links/Config.pm - is the default config file, which is base config when creating new databases.
Links/Config_news.pm or Links/Config_faq.pm or Links/Config_links.pm - will be the config of the actual database.
Links/ConfigData.pm - is the default which is base config of new databases.
Links/ConfigData_news.pm or Links/ConfigData_faq.pm or Links/ConfigData_links.pm - will be the config of the actual database.
some other files, templates(?)
The lists above are not quite complete. There is possible that some more modifications are needed and maybe there are some more reasons why the feature would be useful...
I planned to implement this feature, but if Alex decide to implement it into Links SQL in the future, then I will wait until that release.
Alex, let me know your opinion...
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Let me show you, what features I mean by the "Multiple database usage":
- a) by changing the table prefix, so several "links databases" can be created within the same MySQL database.
E.g: we have MySQL database "mysite", and we create new "links databases" using different table prefixes which will look like "lsql_category" or "faq_category" or "news_category" or using anything other prefix.
- b) by creating new MySQL database (or if the user already created a new database, then only by creating the new tables in the selected database)
E.g:
http://www.site.com/cgi-bin/page.cgi?g=Computers/Video&db=faq
or
http://www.site.com/cgi-bin/page.cgi?g=Computers/Video&db=news
Reasons, why the "Multiple database usage" feature would be fine:
Just imagine that a faq database does not need so frequent backups like a links or news database. So if you have faq, news & links, then it's logical to store them in separate "links databases" not in just one.
A website having several services with high traffic using dynamic page display, may slow down because of locks. Using separate tables or databases, much higher traffic is possible per service.
Well, in overall, there are quite a few places where the "multiple database" feature needs modification, but I think it's not a very difficult job. However requires many similar modifications across many dynamic cgi files, some in the admin interface, and maybe some in a few other .pm files.
Modifications required:
The lists above are not quite complete. There is possible that some more modifications are needed and maybe there are some more reasons why the feature would be useful...
I planned to implement this feature, but if Alex decide to implement it into Links SQL in the future, then I will wait until that release.
Alex, let me know your opinion...
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...