In terms of data, page1.css and page2.css are both generated from multi-dimensional arrays. With that said, page3.css will be a combination of page1.css and page2.css array data.
With me so far?
In terms of database storage, should I store the 1) original array data, 2) raw CSS, or 3) a delimited string?
In other words, when my script creates the third page, it has to combine pages one and two… How should I store the data from the first and second pages in the database in order to generate a third, combined, css page?
I hope that makes sense…
I am not looking for code, I am just curious 'bout best practices. Seems like maybe a delimited string would be a good option… Or would storing the full CSS page and applying string replace functions be just as fast? Or, would storing the original arrays be the best option? It seems like storing the original arrays would be the option with the least amount of fuss (I already have the PHP to parse the arrays and generate a CSS page), but is storing array data in the DB not good practice?
I think that is a bit of an overkill. I don’t see any problem with storing a serialized array for each page of CSS. So given 3 pages you would have three rows. Each row would contain a serialized array of the CSS data.
storing a serialized array has the disadvantage that it makes searching for a particular value cumbersome and slow – you basically have to retrieve every row and inspect it to see if it contains the value you’re looking for
in database terms this is painful, although i daresay that for only a few hundred rows, you won’t really notice the difference
but who here among us has not asked at some point “gee i wish i knew which page uses this particular css class” and then had to look at each one – tedious, innit
Normalizing CSS is going to become a disaster. If there is no need to ever access declaration or rule data at the database level then separating everything out into separate tables is a huge overkill and will be management nightmare. If all you need to do is store the data to rebuild the page then just store the array in a serialized format. You’ll thank yourself later.
I have tried the serialized approach to start out with… So far the table is looking well organized:
Both ‘container’ and ‘margin’ are primary keys. I opted to not include an primary key “id” column (not sure if this is good practice or not):
CREATE TABLE my_table(
container INT NOT NULL,
margin INT NOT NULL,
data TEXT NOT NULL,
tm timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
PRIMARY KEY(container, margin)
Essentially, the user will input a container/margin and the css page is based on those values. When the next user requests a page, if it (container/margin) is not already in the table, then a new entry gets added.
I am still experimenting with both your guys ideas… Thanks so much to both of you for the feedback. :spf:
So, for each container/margin, the “foundation” array is different.
Because I am storing the original array, I can generate (and cache) the third page (i.e. combine the css, like I wanted to do in my original post) via the controller and/or the view (I am using the CodeIgniter php framework).
With that said, do you think I should use a blob? Or, do you use a blob to store static stuff (like CSS that does not change, but is needed on every page)?
How much of the css is common to all the pages? Keep the common css stuff in a normal css file on the server and for each pages css, keep the CSS stored in a BLOB field. echo the css specific for the page to the style section of the HTML page.
I am currently storing the common css in an external file (like you suggest), but I have yet to look at using blobs. Hmmm, maybe I could store both the blob’ed css and the orignal css array – The best of both worlds!
Thanks for the tips! I may be back with more questions.