| Author |
 Topic  |
|
|
alex042
Average Member
USA
631 Posts |
 Posted - 15 May 2002 : 12:31:27
|
I've noticed when implementing some of the mods that several of them seem to create extra unneeded tables when current tables can be used by adding a numeric field or two. Some mods may add onto tables but with some of the fields being text or memo fields, this can create increased file size when the database is allocating extra space for these unused fields. I've also noticed that some of the mods would perform the same functions of a previously posted mod with a couple of minor changes. If some of the current tables are used instead of creating new ones, some MODs can actually be enhanced by default by providing already available features for that table.
For example, articles, announcements, auctions, classifieds, and guestbook, faq, and tips & tricks mods are basically just forums with maybe a couple of features changed such as adding a price, allowing anonymous posting or posting to another page. File related mods or other linking mods such as file library, avatars, pictures, and links can basically be a topic level forum URL with categories and even types (forums). Subscription mods such as bookmarks, buddylists, allowed members, and subscriptions are basically just linking ids with other ids effecting doing the same function.
I've started integrating mods and streamlining them as I go, but it's taking quite a while. But by doing this, I've been able to enhance some mods. For example, by integrating the events mod into a forum instead of its own table, I now have access for people to post and reply to events and can have it show up on the events calendar once approved. And by integrating a subscription type mod/table into that, I should be able to allow for registration to the event. Also, by modifying a slash mod, I can now post an announcement to a forum and have it show up on my front portal page instead of posting it to its own table. This allows for responses to announcements as a regular forum.
Is there any advantage in leaving mods as-is other than installation time? It seems like it would be easier to build on base mods by type than recreating new mods and tables.
Edited by - alex042 on 15 May 2002 12:38:11 |
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 15 May 2002 : 13:04:52
|
however, we recomend that your mods be as modular as possible, with as little change to the base code and tables as possible, that way it makes upgrading to future releases a lot simpler.
|
 |
|
|
@tomic
Senior Member
USA
1790 Posts |
Posted - 15 May 2002 : 13:30:19
|
Articles don't work well with the forums or at least they didn't for me. One example is what do you do when you have an article that's written by someone that is not a forum member? Everything on your site might not relate directly to your forum. Trying to just seems to limit what you can do. It might seem neat and tidy to have everything in the forum and from one angle you are right but Huwr's point is a very good one, too.
@tomic
http://www.skepticfriends.org |
|
|
|
Anacrusis
Junior Member
USA
219 Posts |
Posted - 15 May 2002 : 14:16:28
|
I can see your point, but most of the time it's not logical. When you try implementing all these mods into one or two tables. Then these one or tables will get hammered with requests and eventually bog the database down, It's best, imho, to disperse the load amongst different tables. It also makes for a cleaner databse when things are more categorized into seperate tables.
That's just my personal opinion, feel free to disagree. 
Adam Tommasi
www.inetclubhouse.com |
|
|
|
alex042
Average Member
USA
631 Posts |
Posted - 15 May 2002 : 14:29:28
|
I've also considered modularity when I started integrating these mods. This was a problem I found with MaxWebPortal which had integrated so much non-documented code that it made upgrading the forums to a newer version difficult so I decided to start from the base snitz forum and add the mods myself. I'm going through all of my code to make sure mods are documented within the code as well as notes in the database as to which mods were used to install them.
In the examples I used, the changes to the annoucement mod hasnt required changes to the database yet, it just required changes in the asp page. The calendar has so far been the same with rewriting of the mod pages to integrate into the current database tables. Most of the snitz database table modifications have been to just a few tables. ie: members and topics. For some of the mods, such as active users & pm's, I thought it was appropriate to create the additional tables as they wouldn't have fit into the current tables well, but say, a new logging mod might be able to make use of the active user mod to log other features instead of creating a new log table. Just as some mods may be able to make use of the unused polling fields of a non-poll topic if polling is to be maintained in the topic table. Or another type of email mod may make use of the pm table.
As for snitz asp pages, I try to notate any mod changes that are required and have been trying to avoid changes to them other than a link to hopefully a somewhat self-contained set of asp pages. In fact, I've been trying to separate mods into their own folders as with the events mod which is in its own folder. However, I've had a few problems with the application variables when I do this.
The idea is to use common tables and code between mods to make integrating them easier and more efficient and yet retain the base snitz code. I want the forums to be just a section of my entire portal, and not the only feature available, but I think it has a good base to develop onto.
A note on the table user load: I've been considering this also. I'm not suggesting consolidating the snitz tables, but to have the mod tables make use of the tables that are already available whether they be snitz tables or mod tables already installed. I can see your point about people wanting to actually see the tables separated for that module whether it be for load purposes or appearance, but this can be accomplished through duplicated tables with the name changed. Mods integrated into current tables are a lot easier to separate out into their own tables if the load becomes a problem than they are to put them into the current tables once the mod is installed. As part of my site, I'd like to put a section up for online diaries which are basically forums, but with the popularity of diary sites, I would most likely use a separate database or set of forum tables for this just because of the load. Load can also be dispersed among replicated databases also which is what we've had to impliment where I work.
Edited by - alex042 on 15 May 2002 14:46:26 |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 15 May 2002 : 14:44:49
|
we tried this once with the forum_mods to try and have a common base table to keep mod config informatione, but we unfortunately can't make people code the way we want and not everyone uses it, plus now that we have changed forum_config to a different format, it is possible to use that table instead of the mod table.
I certainly wouldn't advise adding many more fileds to members, it is quiet a hefty table in terms of field number/size as it is. I would also not advise adding fileds to TOPIC or REPLY tables, these are the heaviest hit tables after all.
|
|
|
|
alex042
Average Member
USA
631 Posts |
Posted - 15 May 2002 : 15:01:39
|
I did notice that the members and topics tables were both getting bulky, but I personally haven't needed to add fields to these tables as many other mods such as pm, active users, polls, avatar, birthdate, phonebook, etc have already added several fields to these tables. I had thought about actually adding another members table for the extended profile information just for the mods. And was considering a different way to do the polling as the current polling mod adds several bulky text fields to the topics table. This polling feature would also serve a dual purpose for my site as I could also use it for ratings.
The config table is one of the things that seems to make upgrading MaxWebPortal difficult also which is why I opted to rebuild a portal. As for forum_mods, I think about the only thing I've seen for that so far is the slash mod if I'm thinking of the same thing. And as for integrating the forum_mod variable into the new config table, I've already done that with the one forum_mod, the slash mod, I did find.
I just hope the new version will be an easy upgrade.
|
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 15 May 2002 : 16:22:43
|
quote:
I did notice that the members and topics tables were both getting bulky, but I personally haven't needed to add fields to these tables as many other mods such as pm, active users, polls, avatar, birthdate, phonebook, etc have already added several fields to these tables. I had thought about actually adding another members table for the extended profile information just for the mods. And was considering a different way to do the polling as the current polling mod adds several bulky text fields to the topics table. This polling feature would also serve a dual purpose for my site as I could also use it for ratings.
You could check out my modded download, the polls do not use the toic tables, they have there own, might help you change yours.
|
|
|
|
alex042
Average Member
USA
631 Posts |
Posted - 16 May 2002 : 17:09:46
|
quote:
You could check out my modded download, the polls do not use the toic tables, they have there own, might help you change yours.
It looks like you've added quite a few of the MOD's in your modded version. Although this means it would inherit the pro's and con's of the MOD's the way they're currently written, it would allow for an easy install. This may be a temporary solution to play with until the new version is published. I'm just leary about doing too much coding either way since I don't know how anything I do will integrate into the new version especially since the new version seems near completion.
Btw, is that version of the poll mod available as a download? The version I have includes the fields in the topics table.
Edited by - alex042 on 16 May 2002 22:41:34 |
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 16 May 2002 : 23:02:11
|
Do a search for some article on database normalization and you'll find theres a few rules that are generally accepted as being best practice when designing databases.
I would say Snitz base at the moment is somewhere close to being 1NF though due to supporting multiple DBMS its not quite perfect. Ideally Keys and Relationships should be used to greater effect to achieve the same as what you have by combining the data into fewer tables. Again though this is difficult to do without getting into DBMS specific SQL.
The basic principle for 1NF databases is to keep related data together in the same table which Snitz does pretty well now, ie _MEMBERS contains member registration _TOPICS the topics _REPLIES the replies etc.
Dont foget also that there are maximum row sizes enforced in most Databases, 8k I think is the max for instance for a sqlserver7 row (expanded greatly in 2000 iirc) so adding many new columns to an existing table could result in unexpected errors down the track.
www.daoc-halo.com |
|
|
|
alex042
Average Member
USA
631 Posts |
Posted - 17 May 2002 : 08:29:27
|
quote:
The basic principle for 1NF databases is to keep related data together in the same table which Snitz does pretty well now, ie _MEMBERS contains member registration _TOPICS the topics _REPLIES the replies etc.
You must be referring to the data itself, whereas, I not only consider the data, but what types of fields containing the data. Several of these MOD's may not contain the same data, they do contain nearly the same fields just with different names.
I've been working with databases for over 5 years with 1/2 of those as a WebMaster and I've already been implementing many normalization rules to my work. I always try to assign key fields to tables and I try to keep related types of data together, but I guess what I consider related someone else may not. I also consider types of fields and avoid filling tables with null spaces and try to avoid redundancy. I also try to relate the tables when possible to create interrelational databases and to inforce database integrity. Over the years, I've developed my clucky databases into actual functioning databases that work pretty well and I've seen some peoples attempt at normalization which just proves to overcomplicate the database when they don't enforce data integrity or relate it correctly.
I'm always learning something new which is why I've decided to get into the actual working of Snitz instead of just installing it out-of-the-box.
|
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 17 May 2002 : 09:32:46
|
Doesn't the data dictate the field anyway ? sure someone people are crazy and use a 50 byte varchar field to hold a "Y" or "N" type boolean flag, but hey they're probaby people with 5 weeks experience in databases not 5 years :)
www.daoc-halo.com |
|
|
|
alex042
Average Member
USA
631 Posts |
Posted - 17 May 2002 : 09:59:10
|
quote:
sure someone people are crazy and use a 50 byte varchar field to hold a "Y" or "N" type boolean flag, but hey they're probaby people with 5 weeks experience in databases not 5 years :)
True. Been there, done that.
|
|
|
| |
Topic |
|
|
|
Topic Locked
