when storing paragraphs of text, how do you delinate them..?

This site is best viewed in a modern browser with JavaScript enabled.

when storing paragraphs of text, how do you delinate them..?

toptomato

Hi,
I need a table column to store 2 or 3 paragraphs per entry so am using data type text. How would you delineate between paragraphs if not using HTML <p> tags?

and/or is that the best choice of datatypes to store 2-3 paragraphs of text?

big thanks for any help on this

NogDog

Probably the simplest way is to just separate paragraphs with a newline character. Therefore, each paragraph would be one unbroken string. Then when you pull it out of the DB and want to display it, just replace that newline as needed for the desired output type, e.g. (assuming a PHP app in this case outputting HTML):

echo "<p>".str_replace("\n", "</p>\n<p>", $textFromDatabase)."</p>\n";

toptomato

thanks NogDog,

Rukbat

If you're using the text to display it in a browser, I'd store it with <p> tags. Why have to convert after selecting? It may eventually cost you another MB or two of storage space, but that's pretty negligible these days, and it will matter less in the future.

NogDog

Rukbat;1233049 wrote:
If you're using the text to display it in a browser, I'd store it with <p> tags. Why have to convert after selecting? It may eventually cost you another MB or two of storage space, but that's pretty negligible these days, and it will matter less in the future.

The main reason I would not normally do this is that you would then be adding characters to the data whose only purpose is for formatting in HTML, breaking the separation between view and model -- potentially adding complications to DB searches against that data and adding extra work if you ever want to use that data for purposes other than output to a HTML page.

Now, if you're pretty sure going into things that the only purpose for that data is to be displayed as HTML and either you won't need to search against it or are willing to deal with HTML tags in it while searching against it, then it would not be a big deal either way, I suppose -- but data tends to have a life of its own and is often more important than the application, these days.

Rukbat

NogDog;1233115 wrote:
The main reason I would not normally do this is that you would then be adding characters to the data whose only purpose is for formatting in HTML, breaking the separation between view and model -- potentially adding complications to DB searches against that data and adding extra work if you ever want to use that data for purposes other than output to a HTML page.

Formatting after you get the data from the database takes a finite amount of time. The goal is to get the page to the user as fast as possible. (It's been found that a large majority of users will leave the page if it takes anything over 5 seconds total time to display the entire page.) Javascript execution takes time, page rendering takes time. I'd rather have to spend more drive space and less formatting time, to ensure that the page leaves the server almost instantaneously.

If I need the same text formatted differently, I'll store a copy of it formatted that way too. 2GB of high quality SATA storage is under $100.

NogDog

But it's not drive space that I'm worried about: it's data integrity. If the millisecond (if that much) it would take, say, PHP to run a str_replace() on the retrieved text is important to you, then by all means address it accordingly as you see fit, whether it's data replication, some sort of caching system, or just saying screw the data and put the HTML markup right in the DB. I personally feel that in 99.9% of cases that's probably a premature optimization of very limited value -- especially since, as you point out, hardware is cheap these days, and if you are getting the type of traffic where a millisecond matters, you can probably afford a load balancer and another web server or two.

Rukbat

NogDog;1233237 wrote:
But it's not drive space that I'm worried about: it's data integrity.

The data will be neither corrupted nor stolen (that's data integrity) by storing HTML line ends.

If the millisecond (if that much) it would take, say, PHP to run a str_replace() on the retrieved text is important to you, then by all means address it accordingly as you see fit, whether it's data replication, some sort of caching system, or just saying screw the data and put the HTML markup right in the DB. I personally feel that in 99.9% of cases that's probably a premature optimization of very limited value -- especially since, as you point out, hardware is cheap these days, and if you are getting the type of traffic where a millisecond matters, you can probably afford a load balancer and another web server or two.

You're looking at the server load, I'm looking at the user experience. It depends on how much data you're storing this way, but for scalability, I assume it's going to grow, so I'll do whatever it takes to make sure that the user gets a full page in as short a time as possible. As you say, hardware is cheap, so I don't care about the server load. But I do care about users going to another site because they got bored waiting for my page to load.

gk53

If you cares about both server load and response time save add another field in database and store html formatted textx and original text for search use original for display formatted... it is takes additional server HD which now not a question...