Results 1 to 12 of 12
  1. #1
    Join Date
    Oct 2011
    Location
    Arizona
    Posts
    24

    Need help with Data-Model for Articles

    Hi there!

    I am building a website which provides content/articles to help Small-Businesses, and as it turns out, creating a Data Model that scales well - but which is not overly complex - seems to be much more difficult than I originally thought?!

    Here is some background about the content...

    My website will be divided "Sections". There will be maybe 5-6 of these, and each one will be represented by a navigation tab and a corresponding "landing page".

    These will include:
    Code:
    - Finance
    - Legal
    - Management
    - Operations
    - Marketing
    (This list could change somewhat, but it is unlikely.)


    When a user chooses a "Section", he/she is taken to a "Section Landing Page" that contains "Sub-Sections" - denoted by boxed areas - which contain hyperlinks to Articles for the given Sub-Section.

    So far, so good...

    However, where things started to get "sticky" was the fact that I had maybe 20-40 different ways to sub-divide each Section?!

    One option would be to just map these 20-40 random "Sub-Sections" to a given "Section", but that would be confusing.

    Another option would be to further sub-divide each Section (e.g. Section > Sub-Section > Sub-Sub-Section > Sub-Sub-Sub-Section,...), but that would be a real maintenance nightmare?!

    So, instead, I created the concept of a "Dimension", which is an *intermediary* step between a "Section" and a "Sub-Section".

    You can think of a "Dimension" as a way to logically group certain "Sub-Sections" together based on some common concept (e.g. "Business-Type").

    Most "Dimensions" will map to every Section, but there are some that will only map to a particular Section.

    Here are some examples of "Dimensions" and their corresponding "Sub-Sections"...

    Code:
    Business-Structure: (all)
    - Sole Proprietorship
    - Partnership
    - LLC
    - S-Corp
    - C-Corp
    Code:
    Store-Type: (all)
    - Brick-and-Mortar
    - Online
    - Hybrid
    Code:
    Offering: (all)
    - Products
    - Services
    - Full-Service
    Code:
    Accounting: (Finance-only)
    - Book-Keeping
    - Payroll
    - Taxes

    (There is another concept that I need help with, but it's better to get a basic Data Model built first, before I confuse things too much!!)


    Where I struggling the most is how to properly tie a "Section" to an end "Article"...


    Below is what I have so far...


    Business Rules:
    - One SECTION can have one or more DIMENSIONS

    - One DIMENSION can be associated with one or more SECTIONS

    - Some DIMENSIONS will only map to a particular SECTION (e.g. "Accounting" ---> "Finance")

    - Most DIMENSIONS will map to every SECTION

    - One DIMENSION is made up of one or more SUBSECTIONS

    - One SUBSECTION belongs to one and only one DIMENSION (This could change, but for now, let's assume this is true.)

    - One SUBSECTION will have one or more ARTICLES

    - One ARTICLE will map to one or more SUBSECTIONS

    - An ARTICLE cannot "exist" outside of a SUBSECTION


    Tables:

    SECTION
    - id (PK)
    - slug (UK)
    - name (UK)
    - created_on
    - updated_on


    SECTION_DIMENSION
    - id (PK)
    - section_slug (FK)(UK1)
    - dimension_slug (FK)(UK2)
    - created_on
    - updated_on


    DIMENSION
    - id (PK)
    - slug (UK)
    - name (UK)
    - created_on
    - updated_on


    SUBSECTION
    - id (PK)
    - dimension_slug (FK)
    - slug (UK)
    - name (UK)
    - created_on
    - updated_on


    SUBSECTION_ARTICLE
    - id (PK)
    - subsection_slug (FK1)(UK1)
    - article_slug (FK2)(UK2)
    - created_on
    - updated_on


    ARTICLE
    - id (PK)
    - slug (UK)
    - heading (UK)
    - author
    - written_on
    - body
    - references
    - created_on
    - updated_on


    Relationships:

    SECTION -||-----|<- SECTION_DIMENSION ->|-----||- DIMENSION

    DIMENSION -||---------|<- SUBSECTION

    SUBSECTION -||--------|<- SUBSECTION_ARTICLE ->|-------||- ARTICLE


    Questions:
    1.) How does what I have so far look?


    2.) For the SUBSECTION table, would it make sense to make my PK a combination of the parent Dimension Slug and the Subsection Slug like this...

    SUBSECTION
    - dimension_slug (PK1)
    - slug (PK2)(UK)
    - name (UK)
    - created_on
    - updated_on


    3.) How do I tie-together a Section to a Sub-Section?

    Do I take the SECTION_DIMENSION junction table and the SUBSECTION table, and create another junction table called SECTION_DIMENSION_SUBSECTION?

    Or maybe take the SECTION and DIMENSION and SUBSECTION tables independently and form a junction table called SECTION_DIMENSION_SUBSECTION?

    Or something else?


    3.) How do I link a SECTION (and even a DIMENSION) to an ARTICLE?

    This is where I get all mixed up?!

    Sincerely,


    Debbie

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    This smells like a Nested Set problem to me. Maybe Joe Celko will pop by and offer a suggestion or two!

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  3. #3
    Join Date
    Oct 2011
    Location
    Arizona
    Posts
    24
    Quote Originally Posted by Pat Phelan View Post
    This smells like a Nested Set problem to me. Maybe Joe Celko will pop by and offer a suggestion or two!

    -PatP
    What is a "Nested Set" problem?

    And who is "Joe Celko"?

    Sincerely,


    Debbie

  4. #4
    Join Date
    Jan 2013
    Posts
    354

    Sic transit gloria mundi

    I spent 10 years on the ANSI X3H2 Database Standards and written a series of books on SQL. I go back to SQL in the 1970's.

    One of those books is TREES & HIERARCHIES IN SQL. The title tells you the topic, but you can google the table of contents.

    Since SQL is a set oriented language, this is a better model than the usual adjacency list approach you see in most text books. Let us define a simple OrgChart table like this.

    CREATE TABLE OrgChart
    (emp_name CHAR(10) NOT NULL PRIMARY KEY,
    lft INTEGER NOT NULL UNIQUE CHECK (lft > 0),
    rgt INTEGER NOT NULL UNIQUE CHECK (rgt > 1),
    CONSTRAINT order_okay CHECK (lft < rgt));

    OrgChart
    emp_name lft rgt
    ======================
    'Albert' 1 12
    'Bert' 2 3
    'Chuck' 4 11
    'Donna' 5 6
    'Eddie' 7 8
    'Fred' 9 10

    The (lft, rgt) pairs are like tags in a mark-up language, or parens in algebra, BEGIN-END blocks in Algol-family programming languages, etc. -- they bracket a sub-set. This is a set-oriented approach to trees in a set-oriented language.

    The organizational chart would look like this as a directed graph:

    Albert (1, 12)
    / \
    / \
    Bert (2, 3) Chuck (4, 11)
    / | \
    / | \
    / | \
    / | \
    Donna (5, 6) Eddie (7, 8) Fred (9, 10)

    This has some predictable results that we can use for building queries. The root is always (left = 1, right = 2 * (SELECT COUNT(*) FROM TreeTable)); leaf nodes always have (left + 1 = right); subtrees are defined by the BETWEEN predicate; etc. Here are two common queries which can be used to build others:

    1. An employee and all their Supervisors, no matter how deep the tree.

    SELECT O2.*
    FROM OrgChart AS O1, OrgChart AS O2
    WHERE O1.lft BETWEEN O2.lft AND O2.rgt
    AND O1.emp_name = :in_emp_name;

    2. The employee and all their subordinates. There is a nice symmetry here.

    SELECT O1.*
    FROM OrgChart AS O1, OrgChart AS O2
    WHERE O1.lft BETWEEN O2.lft AND O2.rgt
    AND O2.emp_name = :in_emp_name;

    3. Add a GROUP BY and aggregate functions to these basic queries and you have hierarchical reports. For example, the total salaries which each employee controls:

    SELECT O2.emp_name, SUM(S1.salary_amt)
    FROM OrgChart AS O1, OrgChart AS O2,
    Salaries AS S1
    WHERE O1.lft BETWEEN O2.lft AND O2.rgt
    AND S1.emp_name = O2.emp_name
    GROUP BY O2.emp_name;

    4. To find the level and the size of the subtree rooted at each emp_name, so you can print the tree as an indented listing.

    SELECT O1.emp_name,
    SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt
    THEN O2.sale_amt ELSE 0.00 END) AS sale_amt_tot,
    SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt
    THEN 1 ELSE 0 END) AS subtree_size,
    SUM(CASE WHEN O1.lft BETWEEN O2.lft AND O2.rgt
    THEN 1 ELSE 0 END) AS lvl
    FROM OrgChart AS O1, OrgChart AS O2
    GROUP BY O1.emp_name;

    5. The nested set model has an implied ordering of siblings which the adjacency list model does not. To insert a new node, G1, under part G. We can insert one node at a time like this:

    BEGIN ATOMIC
    DECLARE rightmost_spread INTEGER;

    SET rightmost_spread
    = (SELECT rgt
    FROM Frammis
    WHERE part = 'G');
    UPDATE Frammis
    SET lft = CASE WHEN lft > rightmost_spread
    THEN lft + 2
    ELSE lft END,
    rgt = CASE WHEN rgt >= rightmost_spread
    THEN rgt + 2
    ELSE rgt END
    WHERE rgt >= rightmost_spread;

    INSERT INTO Frammis (part, lft, rgt)
    VALUES ('G1', rightmost_spread, (rightmost_spread + 1));
    COMMIT WORK;
    END;

    The idea is to spread the (lft, rgt) numbers after the youngest child of the parent, G in this case, over by two to make room for the new addition, G1. This procedure will add the new node to the rightmost child position, which helps to preserve the idea of an age order among the siblings.

    6. To convert a nested sets model into an adjacency list model:

    SELECT B.emp_name AS boss_emp_name, E.emp_name
    FROM OrgChart AS E
    LEFT OUTER JOIN
    OrgChart AS B
    ON B.lft
    = (SELECT MAX(lft)
    FROM OrgChart AS S
    WHERE E.lft > S.lft
    AND E.lft < S.rgt);

    7. To find the immediate parent of a node:

    SELECT MAX(P2.lft), MIN(P2.rgt)
    FROM Personnel AS P1, Personnel AS P2
    WHERE P1.lft BETWEEN P2.lft AND P2.rgt
    AND P1.emp_name = @my_emp_name;

    TREES & HIERARCHIES IN SQL has a lot of other programming idioms for nested sets.

  5. #5
    Join Date
    Oct 2011
    Location
    Arizona
    Posts
    24
    Quote Originally Posted by Celko View Post
    I spent 10 years on the ANSI X3H2 Database Standards and written a series of books on SQL. I go back to SQL in the 1970's.

    One of those books is TREES & HIERARCHIES IN SQL. The title tells you the topic, but you can google the table of contents.

    Since SQL is a set oriented language, this is a better model than the usual adjacency list approach you see in most text books. Let us define a simple OrgChart table like this.
    Nice to meet you, Celko, and thanks for the dissertation on your theory, but I don't see how that has anything to do with my OP or my questions...

    Sincerely,


    Debbie

  6. #6
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    If you think about the sets that Joe was talking about as your sections, sub-sections, etc. then his answer is a near perfect fit for your problem. The advantages are that using his method you don't get tied up in how many levels there are, how many things are at, in, or below each level.

    It gets your code out of having to deal with the complexity of managing the hierarchy of your levels and sub levels and pretty much allows you to deal with everything as though it were "flat" instead of as a tree, but it allows you to easily reconstruct the tree (or any sub-set of it) at will.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  7. #7
    Join Date
    Oct 2011
    Location
    Arizona
    Posts
    24
    So I was up late last night racking my brain, trying to figure things out. To help out, I created some data which should pretty closely match what I will be doing in real-life.

    After doing that, I tweaked my ERD to look like this...
    Code:
    SECTION -||-----|<- SECTION_DIMENSION ->|------||- DIMENSION
    
    DIMENSION -||-----|<- DIMENSION_SUBSECTION ->|-----||- SUBSECTION

    And here is the data that I created...

    SECTION
    Code:
    Finance
    Legal

    DIMENSION
    Code:
    Business Structure
    Store Type
    Offering
    Accounting
    Featured Legal

    SECTION_DIMENSION
    Code:
    SECTION		DIMENSION
    --------	----------
    Finance		Business Structure
    "		Store Type
    "		Offering
    "		Accounting
    Legal		Business Structure
    "		Store Type
    "		Offering
    "		Featured Legal

    Looks good so far...


    SUBSECTION
    Code:
    Sole Proprietorship
    Partnership
    LLC
    S-Corp
    C-Corp
    Brick & Mortar
    Online
    Hybrid
    Products
    Services
    Full Service
    Bookkeeping
    Payroll
    Taxes
    General Counsel
    Copyrights & Patents
    Tax Law
    Litigation

    DIMENSION_SUBSECTION
    Code:
    DIMENSION		SUBSECTION
    ----------		-----------
    Business Structure	Sole Proprietorship
    "			Partnership
    "			LLC
    "			S-Corp
    "			C-Corp
    Store Type		Brick & Mortar
    "			Online
    "			Hybrid
    Offering		Products
    "			Services
    "			Full Service
    Accounting		Bookkeeping
    "			Payroll
    "			Taxes
    Featured Legal		General Counsel
    "			Copyrights & Patents
    "			Tax Law
    "			Litigation
    Still looking good to me...

    But where I am stuck is determining how to join SECTION and DIMENSION and SUBSECTION so I can tie these entities to an ARTICLE?!


    Is there a way that I can join the tables SECTION_DIMENSION and DIMENSION_SUBSECTION?


    Or, I should take each component table - separately - and create a junction table like this...


    SECTION_DIMENSION_SUBSECTION
    Code:
    SECTION		DIMENSION		SUBSECTION
    --------	----------		-----------
    Finance		Business Structure	Sole Proprietorship
    "		"			Partnership
    "		"			LLC
    "		"			S-Corp
    "		"			C-Corp
    "		Store Type		Brick & Mortar
    "		"			Online
    "		"			Hybrid
    "		Offering		Products
    "		"			Services
    "		"			Full Service
    "		Accounting		Bookkeeping
    "		"			Payroll
    "		"			Taxes
    Legal		Business Structure	Sole Proprietorship
    "		"			Partnership
    "		"			LLC
    "		"			S-Corp
    "		"			C-Corp
    "		Store Type		Brick & Mortar
    "		"			Online
    "		"			Hybrid
    "		Offering		Products
    "		"			Services
    "		"			Full Service
    "		Featured Legal		General Counsel
    "		"			Copyrights & Patents
    "		"			Tax Law
    "		"			Litigation

    Here is my ARTICLE table...

    ARTICLE
    Code:
    - id
    - slug
    - heading
    - author
    - published_on
    - body
    - reference_list
    - created_on
    - updated_on

    So my final junction table would look like this...

    SECTION_DIMENSION_SUBSECTION_ARTICLE
    Code:
    SECTION		DIMENSION		SUBSECTION		ARTICLE
    --------	----------		-----------		--------
    Finance		Business Structure	Sole Proprietorship
    "		"			Partnership
    "		"			LLC
    "		"			S-Corp
    "		"			C-Corp
    "		Store Type		Brick & Mortar
    "		"			Online			BeSureToChargeSalesTax.php
    "		"			Hybrid
    "		Offering		Products
    "		"			Services
    "		"			Full Service
    "		Accounting		Bookkeeping
    "		"			Payroll
    "		"			Taxes			BeSureToChargeSalesTax.php
    Legal		Business Structure	Sole Proprietorship
    "		"			Partnership
    "		"			LLC
    "		"			S-Corp
    "		"			C-Corp
    "		Store Type		Brick & Mortar
    "		"			Online
    "		"			Hybrid
    "		Offering		Products
    "		"			Services
    "		"			Full Service
    "		Featured Legal		General Counsel
    "		"			Copyrights & Patents
    "		"			Tax Law			BeSureToChargeSalesTax.php
    "		"			Litigation

    That is about the best idea I can come up with...

    Sincerely,


    Debbie

    P.S. I guess I forgot to mention, that it almost seems like I could treat SECTION, DIMENSION, and SUBSECTION as "look-up" tables, and just have one junction table - SECTION_DIMENSION_SUBSECTION for dealing with those 3 entities?
    Last edited by doubledee; 05-05-13 at 15:41. Reason: Additional thought

  8. #8
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    My first choice would be nested sets. This is the most complex code, but it handles as many levels and items as your database can tolerate and the changes to add or move levels are all done in data instead of in the schema itself.

    My Second choice would be your latest, with separate tables for each "widget" level . This is the most intuitive for someone that has never worked with hierarchies before. This is the easiest to code and understand, but by far the hardest to maintain over time.

    Your intermediate proposal (with handling the sub-levels and levels in a single table) would be my third choice. It adds complexity to the simple model with only some beneifts, and it ends up being almost as complex as the Nested Set model if you want to handle all of the "edge cases" without having to change the schema.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  9. #9
    Join Date
    Oct 2011
    Location
    Arizona
    Posts
    24
    Quote Originally Posted by Pat Phelan View Post
    My first choice would be nested sets. This is the most complex code, but it handles as many levels and items as your database can tolerate and the changes to add or move levels are all done in data instead of in the schema itself.
    I would be interested in learning more about this approach, but realistically it is over my head at the moment.

    And I think it is better to work with things that are less sophisticated, but which can be done better (by me), than trying to implement something more sophisticated and winding up breaking everything!!

    If you guys can help me get things up and running with some variant of what I proposed, then I'd love to get all theoretical and try to learn the way that Celko proposed.


    My Second choice would be your latest, with separate tables for each "widget" level . This is the most intuitive for someone that has never worked with hierarchies before. This is the easiest to code and understand, but by far the hardest to maintain over time.
    Because I have posted so much so quickly, you're losing me on which one you approve of...

    Did you like the one I posted this morning which included junction tables between two tables like this...

    Options #1:
    Code:
    SECTION -||-----|<- SECTION_DIMENSION ->|------||- DIMENSION
    
    DIMENSION -||-----|<- DIMENSION_SUBSECTION ->|-----||- SUBSECTION

    If so, then I had some questions above that would need to be answered so I could implement things successfully.


    Or did you like the one where I just have one monster junction table like this...

    Options #2:
    Code:
    SECTION -||-----|<- SECTION_DIMENSION_SUBSECTION
    
    DIMENSION -||-----|<- SECTION_DIMENSION_SUBSECTION
    
    SUBSECTION -||-----|<- SECTION_DIMENSION_SUBSECTION

    If you liked that one, then there is still questions related to how to tie things in with my ARTICLE table.

    In my last post before supper, I had proposed this...
    Code:
    SECTION -||-----|<- SECTION_DIMENSION_SUBSECTION
    
    DIMENSION -||-----|<- SECTION_DIMENSION_SUBSECTION
    
    SUBSECTION -||-----|<- SECTION_DIMENSION_SUBSECTION
    
    SECTION_DIMENSION_SUBSECTION -||--------|<- SECTION_DIMENSION_SUBSECTION_ARTICLE ->|----------||- ARTICLE


    Your intermediate proposal (with handling the sub-levels and levels in a single table) would be my third choice. It adds complexity to the simple model with only some beneifts, and it ends up being almost as complex as the Nested Set model if you want to handle all of the "edge cases" without having to change the schema.
    It seems like you mean Option #2 in this post, but again, I'm unsure...

    Hopefully I am not too far off from a decent Data Model. (This thread is my last "stumbling block" to finishing my website, and I am very stressed and anxious about getting it done, and done right!!)

    Sincerely,


    Debbie

  10. #10
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    First of all, using the name "dimension" is going to cause you heartache because that term is already overused. Programming languages use it to describe multiple unrelated language features. OLAP uses it to describe modeling techniques and abstractions. Scripting languages use it to describe families of scripts. Due to the number of different ways that the word "dimension" is used, it is about as meaningful today as "widget" was twenty years ago!

    Borrowing the Windows / Linux file system model, you have the equivalent of directories and files. The files are the items of real interest to you and your users. The directories are ways to organize those files so that they make sense and so that the user only has to deal with a subset of the whole instead of having to deal with everything at once.

    Using the Nested Set model, all of the complexity is in the code. Once you get the code correct you will never need to change the schema (the table layout) or the code again, all you do is modify the data.

    Using your original suggestion, you'd have a separate table for each layer of the hierarchy. For every logical division or container you'd create a new table and new code to support it. This is easy to see, easy to understand, and a lot of ongoing work because every change requires you to modify your tables and your code.

    Using your latest suggestion would allow you to store the hierarchy within a table or a group of tables. This would allow some changes to be handled via data, and others to be handled via schema and code changes. This is a trade off between the two extremes, but it is likely to be the one that will most frustrate the user because they'll never be completely sure what they can change and what they'll have to ask you to change. It might be a good fit for a "one time shot" like a classroom assignment, but it wouldn't be a good business solution.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  11. #11
    Join Date
    Oct 2011
    Location
    Arizona
    Posts
    24
    Quote Originally Posted by Pat Phelan View Post
    First of all, using the name "dimension" is going to cause you heartache because that term is already overused. Programming languages use it to describe multiple unrelated language features. OLAP uses it to describe modeling techniques and abstractions. Scripting languages use it to describe families of scripts. Due to the number of different ways that the word "dimension" is used, it is about as meaningful today as "widget" was twenty years ago!
    I chose "dimension" because that is exactly what I am modeling...

    And since I am the only person who will ever work on this website, it works best for me.


    Using the Nested Set model, all of the complexity is in the code. Once you get the code correct you will never need to change the schema (the table layout) or the code again, all you do is modify the data.
    Right, except for one crucial thing you are leaving out...

    My website is 8-12 months behind schedule, and I need to get it finished by Memorial Day or I might as well scrap it until next Fall.

    If I understood what you and Celko are proposing I might use it if it met 100% of my needs and requirements - which I am still not sure it does.

    I do know my current design does meet 100% of my needs and requirements. (I just need help hooking up the backend in a semi-eloquent way so I won't kick myself in a couple of months.)


    Using your original suggestion, you'd have a separate table for each layer of the hierarchy. For every logical division or container you'd create a new table and new code to support it. This is easy to see, easy to understand, and a lot of ongoing work because every change requires you to modify your tables and your code.
    I spent a lot of time coming up with a scheme (and schema) that should last me a long time - long enough so that when things change, it won't matter. So I don't see there being lots of changes and hassles.


    Using your latest suggestion would allow you to store the hierarchy within a table or a group of tables. This would allow some changes to be handled via data, and others to be handled via schema and code changes. This is a trade off between the two extremes, but it is likely to be the one that will most frustrate the user because they'll never be completely sure what they can change and what they'll have to ask you to change.
    Who are you thinking the "user" is?

    Um, this is a one woman company and website. There is no one I have to please but me. And there will never be anyone other than me working on this.

    And as far as "users", all they need is an easy-to-use UI which is built upon a logical and expandable back-end which I have already created - less the details of how to set up my tables and joins.

    I think the design I came up with is extremely scalable.

    Again, I appreciate your warnings, but you're making A LOT of assumptions here that just don't apply.

    Would I be interested in learning more about your and Celko's approach? Sure, once I have my solution working.

    But am I willing to gamble on an approach that I do NOT understand, and one that I don't even know if it fits my needs and requirements and risk adding 6 more months to going live to be "cool". NO!!


    It might be a good fit for a "one time shot" like a classroom assignment, but it wouldn't be a good business solution.

    -PatP
    Pat, please don't be insulting, and compare my website and business aspirations to a "classroom assignment".

    I am making "good" business decisions.


    -----
    Moving along... If anyone here is willing to answer the questions I have asked in the posts above, that would be a good start in helping me out.

    I think there are some nuances in the different approaches I mentioned that still need to be worked out and better understood by me. (Which is why I came here for help!!)

    Then after getting that resolved, I would be willing to talk more about this "Set approach".

    Sincerely,


    Debbie

  12. #12
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    If your goal is to get your website up quickly and to have the ability to flexibly handle the content, then you really need to consider using a CMS instead of coding the content and the management yourself. You could have what you've described up before supper time using a CMS!

    I would recommend Drupal or XOOPS based on your requirements in this thread. They have great content management, good catalog/sales tools, and are completely customizable (using PHP which you already seem to prefer).

    People have finite capacities. If business is your passion, engage in that passion and use a CMS. If coding web sites is your passion, engage in that passion and find someone else to run the business. Especially when you are getting started, be very careful how much you try to handle outside of your area of passion... That is a path that all too many startups follow to a quick demise! It nearly killed me (in the literal sense of the word).

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

Posting Permissions

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