Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 4 of 4 FirstFirst ... 234
Results 46 to 49 of 49
  1. #46
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,947
    Thanks
    79
    Thanked 4,424 Times in 4,389 Posts
    You're going to hate me for this..

    Unless you duplicate the name/heading of an article, why do you need to do *ANY* of that?

    Why not simply
    Code:
    SELECT * FROM articles WHERE heading = 'Save Your Taxes For A CPA'
    ???

    The only reason for the sections/dimensions/subsections is for your own organization. Nobody said you had to actually use them when looking for a given article.

    Assuming that YOUR code generates the URL
    Code:
    www.debbie.com/finance/tax-season/save-your-taxes-for-a-cpa
    then you *know* the article exists.

    And if somebody passes you a bogus URL:
    Code:
    www.debbie.com/finance/tax-season/this-is-a-stickup-give-me-all-your-money
    Well, so what if that article doesn't exist? Toss them back to the starting page.

    And if somebody gives you a bogus path:
    Code:
    www.debbie.com/foo/bar/save-your-taxes-for-a-cpa
    all you really need to do is verify that the given section and subsection exist. Or maybe you don't even care.
    Last edited by Old Pedant; 05-16-2013 at 09:44 PM.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  2. #47
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,108
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Old Pedant View Post
    You're going to hate me for this..
    As long as you leave my new Data Model alone, you'll be okay!!


    Unless you duplicate the name/heading of an article, why do you need to do *ANY* of that?

    Why not simply
    Code:
    SELECT * FROM articles WHERE heading = 'Save Your Taxes For A CPA'
    ???

    The only reason for the sections/dimensions/subsections is for your own organization. Nobody said you had to actually use them when looking for a given article.
    I suppose so.


    Assuming that YOUR code generates the URL
    Code:
    www.debbie.com/finance/tax-season/save-your-taxes-for-a-cpa
    then you *know* the article exists.

    And if somebody passes you a bogus URL:
    Code:
    www.debbie.com/finance/tax-season/this-is-a-stickup-give-me-all-your-money
    Well, so what if that article doesn't exist? Toss them back to the starting page.

    And if somebody gives you a bogus path:
    Code:
    www.debbie.com/foo/bar/save-your-taxes-for-a-cpa
    all you really need to do is verify that the given section and subsection exist. Or maybe you don't even care.
    Since my last post, I sketched out on paper what my "Section" page will look like. I also sketched out what a "Sub-Section" page will look like.

    (This was very helpful!!)


    Now back to your points...

    On one hand, yes, because an Article Slug is unique, that is all I would ever need to retrieve an Article.

    However, on the other hand, I guess I want to make sure that any requested Articles have valid URL's associated with them.

    In my mind, doing so maybe acts as a deterrent for people screwing around with the URL trying to surf directories and files.

    By checking the URL, it also allows me to display and log more specific errors, so I can keep a track on what is going on...

    Maybe this is too extreme for you, but I had envisioned taking these steps...

    1.) Verify the "Section" in the URL is valid...

    Code:
    SELECT slug
    FROM section
    WHERE slug = $url_section
    If not, throw a specific error.


    2.) Verify the "SubSection" in the URL is valid for the chosen "Section"... (One or more records)

    Code:
    SELECT sd_section_slug, ds_subsection_slug
    FROM article_placement
    WHERE sd_section_slug = $url_section
    AND ds.subsection_slug = $url_subsection
    If not, throw a specific error.


    3.) Verify the Section/SubSection/Article combination in the URL are valid... (One or more records)

    Code:
    SELECT sd_section_slug, ds_subsection_slug, article_slug
    FROM article_placement
    WHERE sd_section_slug = $url_section
    AND ds.subsection_slug = $url_subsection
    AND article_slug = $url_article
    If not, throw a specific error.


    4.) Query the Article table for the required fields...

    Code:
    SELECT *
    FROM article
    WHERE slug = $url_article
    Do what is needed to display the Article...


    From what most people have told me, the above queries would be "cheap", and there is no reason to fear performing several calls to the database if there is a legitimate reason.

    Sincerely,


    Debbie

  3. #48
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,947
    Thanks
    79
    Thanked 4,424 Times in 4,389 Posts
    At this point, I think whether you do such section/subsection verification is up to you.

    I agree that it's certainly "cheap" enough.

    Let me give you a point of comparison: One of the sites I work on uses MySQL. For some of the pages we display, we have to make as many as perhaps TEN separate queries into as many as THREE DIFFEERENT databases (all on the same MySQL server, though), including some that do cross-database joins.

    That site, *ON AVERAGE* serves up one web page every 1.8 seconds. And we aren't at capacity, at all. (I think we wil be, soon, when we open up another two sites doing roughly the same stuff, so we may go to two separate servers then.)

    If you do the math, that is well over 300,000 pages served up per week.

    How long do you think it will take for you to get to that volume?
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  4. #49
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,108
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Old Pedant View Post
    At this point, I think whether you do such section/subsection verification is up to you.
    I'll consider your suggestions, and see what I think makes the most sense.


    I agree that it's certainly "cheap" enough.
    That's good to know.


    Let me give you a point of comparison: One of the sites I work on uses MySQL. For some of the pages we display, we have to make as many as perhaps TEN separate queries into as many as THREE DIFFEERENT databases (all on the same MySQL server, though), including some that do cross-database joins.

    That site, *ON AVERAGE* serves up one web page every 1.8 seconds. And we aren't at capacity, at all. (I think we wil be, soon, when we open up another two sites doing roughly the same stuff, so we may go to two separate servers then.)
    Those web pages must have been built very well, and your database/queries must be tuned very well to get such great results.

    It's amazing how most web pages end up "choking" with the slightest increase in traffic. (My last client was convinced they need more hardware, when their website was choking with maybe 30-60 concurrent users...)

    I know that I have spent an enormous amount of time - as you have probably figured out by now - on tweaking my HTML and CSS and PHP and SQL and Data Model, so that things are designed in a sophisticated, yet simplistic kind of way.

    To me, when you load a page, or click on a link, things should happen INSTANTLY ---> Think "Yahoo News" circa 1995 before they used JavaScript and had Ads...


    If you do the math, that is well over 300,000 pages served up per week.

    How long do you think it will take for you to get to that volume?
    Hah!! Probably never!!

    (My current v1.0 website averages maybe 30 hits per day...)

    I sure do hope that this revised website that I'm working on does better...

    Thanks,


    Debbie


 
Page 4 of 4 FirstFirst ... 234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •