Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest sNews - sNews 1.7 - with its own forums - for discussion and user mods.

Pages: 1 [2] 3 4

Author Topic: Restructuring the articles table  (Read 21102 times)

invarbrass

  • Full Member
  • ***
  • Karma: 18
  • Posts: 117
    • http://snews.extremebittorrent.com
Re: Restructuring the articles table
« Reply #15 on: February 13, 2008, 04:27:22 AM »

@invar.
I acknowledge that you weren't going to seperate the items. I am suggesting that is what could be done.
Then you will not be storing an extra 80?? - 250?? characters in the db.
These characters (which is the summary text) are duplicated in your approach, making the db significantly larger in a site with masses of articles. Take H.A.C's site of apparently over 10,000 articles. If each article has a 250 character summary, that's over 2,500,000 surplus chars that are replicated.

I agree, all the three methods mentioned so far have their pros and cons. We need to select the best approach for out purpose.

The DB will be larger with the duplicate-summary method, but I think the size increase won't be significant. Taking HAC's site for example, this approach will only increase the DB by only 2.34 MB (for summary size of 250 chars; 750 KB if the summary is 80 characters), provided he does have 10,000 articles. So even for the most extreme case, the trade-off isn't that big. And looking at his site (and others), most of the articles will never be edited in the future. So we could save a whole lot of processing if we just separated the summary from the full article. This will benifit large sites like HAC's.
« Last Edit: February 13, 2008, 04:29:30 AM by invarbrass »
Logged

invarbrass

  • Full Member
  • ***
  • Karma: 18
  • Posts: 117
    • http://snews.extremebittorrent.com
Re: Restructuring the articles table
« Reply #16 on: February 13, 2008, 04:36:30 AM »

I forgot to mention, if you separate the summary and article, you will need to alter the search code as well. But for the "duplication approach", the default search method will work out of the box.
Logged

centered

  • Guest
Re: Restructuring the articles table
« Reply #17 on: February 13, 2008, 04:38:22 AM »

Let's see if we can do away with an extra summary text-box.

Why? Isn't that current functionality?  I would like to see the summary and the full article seperated.  The db doesn't have to access the same information twice and it will be a few lines less code to deal with.
Logged

centered

  • Guest
Re: Restructuring the articles table
« Reply #18 on: February 13, 2008, 04:39:51 AM »

I forgot to mention, if you separate the summary and article, you will need to alter the search code as well. But for the "duplication approach", the default search method will work out of the box.

summary LIKE '%$keywords[$i]%' ?? Not too hard
Logged

invarbrass

  • Full Member
  • ***
  • Karma: 18
  • Posts: 117
    • http://snews.extremebittorrent.com
Re: Restructuring the articles table
« Reply #19 on: February 13, 2008, 04:44:36 AM »

Let's see if we can do away with an extra summary text-box.

Why? Isn't that current functionality?  I would like to see the summary and the full article seperated.  The db doesn't have to access the same information twice and it will be a few lines less code to deal with.

I agree. However, while the "2-editor" approach will be easier (and cleaner) to implement, it's also slightly cumbersome on user-end. Think about it, the user needs to copy-paste the content from the article editor. With the old-style "single-editor" approach, the user needs only to click on the break button.
Logged

Joost

  • Guest
Re: Restructuring the articles table
« Reply #20 on: February 13, 2008, 04:45:22 AM »

@Philmozz!!!!

New avatar? How is it hanging? ;D

Logged

invarbrass

  • Full Member
  • ***
  • Karma: 18
  • Posts: 117
    • http://snews.extremebittorrent.com
Re: Restructuring the articles table
« Reply #21 on: February 13, 2008, 04:46:14 AM »

I forgot to mention, if you separate the summary and article, you will need to alter the search code as well. But for the "duplication approach", the default search method will work out of the box.

summary LIKE '%$keywords[$i]%' ?? Not too hard

Not too hard for me either, but it certainly won't be too easy for the database engine which has to search an extra field...  ;) Not to mention snews' default search function isn't exactly top-notch.
« Last Edit: February 13, 2008, 04:48:22 AM by invarbrass »
Logged

centered

  • Guest
Re: Restructuring the articles table
« Reply #22 on: February 13, 2008, 04:56:16 AM »

Quote
Not too hard for me either, but it certainly won't be too easy for the database engine which has to search an extra field...  ;)

or to retrieve a field it wont use (select *)?
select title, seftitle, date, category from articles ...

Logged

philmoz

  • High flyer
  • ULTIMATE member
  • ******
  • Karma: 161
  • Posts: 1988
    • fiddle 'n fly
Re: Restructuring the articles table
« Reply #23 on: February 13, 2008, 04:56:44 AM »

search... damn, that one always bites me. :)
... and just had to try searching for [break]... it is not invisible to search.
Just did this on HAC's site... 17590 results were found for query [break].

ok, assuming searching the 'seperated' summary can be easily overcome, what would the overhead be when concatenating summary and rest as I put forward, as opposed to pulling full ([break]less) article from db?

hmmm, aaaand, [break] detection determines if short article is or is not shown.
So, that detection would need to be done using the new articles.summary field. (ie:- empty or not)
If the admin removes the [break], (converting to page type, or extra type article), then emptying the summary field in both cases is required.
Also need to look at what else is affected if the [break] tag is not actually stored with the text.
Logged
Of all the things I have lost, it is my mind that I miss the most.

centered

  • Guest
Re: Restructuring the articles table
« Reply #24 on: February 13, 2008, 04:57:28 AM »

Not to mention snews' default search function isn't exactly top-notch.

Not the first one to mention that... care to elaborate?

Logged

centered

  • Guest
Re: Restructuring the articles table
« Reply #25 on: February 13, 2008, 05:00:01 AM »

ok, assuming searching the 'seperated' summary can be easily overcome, what would the overhead be when concatenating summary and rest as I put forward, as opposed to pulling full ([break]less) article from db?

I would assume the overhead would be less than the db pulling the entire article and doing nothing with the remainder after the break function...
Logged

philmoz

  • High flyer
  • ULTIMATE member
  • ******
  • Karma: 161
  • Posts: 1988
    • fiddle 'n fly
Re: Restructuring the articles table
« Reply #26 on: February 13, 2008, 05:06:54 AM »

@equilni
I think we can all agree on that .
Logged
Of all the things I have lost, it is my mind that I miss the most.

invarbrass

  • Full Member
  • ***
  • Karma: 18
  • Posts: 117
    • http://snews.extremebittorrent.com
Re: Restructuring the articles table
« Reply #27 on: February 13, 2008, 05:07:23 AM »

Quote
Not too hard for me either, but it certainly won't be too easy for the database engine which has to search an extra field...  ;)
or to retrieve a field it wont use (select *)?
select title, seftitle, date, category from articles ...
Exactly, for index pages:
select title, id, summary...
And the article pages:
select title, id, atext...
Logged

invarbrass

  • Full Member
  • ***
  • Karma: 18
  • Posts: 117
    • http://snews.extremebittorrent.com
Re: Restructuring the articles table
« Reply #28 on: February 13, 2008, 05:14:51 AM »

search... damn, that one always bites me. :)
... and just had to try searching for [break]... it is not invisible to search.
Just did this on HAC's site... 17590 results were found for query [break].

ok, assuming searching the 'seperated' summary can be easily overcome, what would the overhead be when concatenating summary and rest as I put forward, as opposed to pulling full ([break]less) article from db?

here's a comparison that comes to mind:
separate summary and rest of the article:
search: the database has to perform search on two separate fields... possible overhead?
article page: retrieve both summary and atext fields, contatenate them to get the full text... overhead here also

break-less article:
search: works right out of the box, no overhead
article page: retrieve the atext field only, no need for processing... no overhead
Logged

philmoz

  • High flyer
  • ULTIMATE member
  • ******
  • Karma: 161
  • Posts: 1988
    • fiddle 'n fly
Re: Restructuring the articles table
« Reply #29 on: February 13, 2008, 05:18:47 AM »

Exactly, for index pages:
select title, id, summary...
And the article pages:
select title, id, atext...
except if someone chooses not to [break] an article (because it's rather short, maybe) in which case only a link will be shown (will it??) as there is no summary field content[[error handling required here as well maybe]]. (currently, if no [break], full (but short in total length) article is displayed.)
What would be desirable??
« Last Edit: February 13, 2008, 05:20:19 AM by philmoz »
Logged
Of all the things I have lost, it is my mind that I miss the most.
Pages: 1 [2] 3 4