Recommendation needed for text content, should I use text files or database?

I'm doing a web application in asp.net mvc. Now I'm at the point where I do alot of text info such as help texts, eula, privacy policy etc. I realized that I'm not sure what would the best way to store these texts. 1. Directly in the aspx page 2. In text files and then load the text via ViewData[] to the aspx file 3. In my sql database

If use option 3 how would I then design the database e.g. eula = table x, privacypolicy=table y?

I guess I just n开发者_C百科eed some directions of what't the pros and cons with the options above.

---

1. Directly in the ASPX page -> hell no! . You will have to re-compile and publish for every change. that's terrible.

2. Text files will enable you to use easier caching in case this data doesn't frequently change, but text files are horrible in so many different ways. At the end you will have dozens/hundreds of text files and no idea what references what. (So you will have to keep a database table anyway with pointers to the files).

3. Which leads to the only possible solution here, saving everything in the database. You can also use caching or even, if it's not a lot, store everything in an Application variable which will be re-indexed every iisreset.

4. Don't have much experience with that, but maybe using LocalResources will be a good idea. This will enable you (if needed) multiple language support further on.

---

If your app is really small, keeping the text in the pages might be ok, but as soon as the app and the team behind it grows, this might become a problem. Things like handing of text to a professional writer, translations, proofreading by a lawyer will be bothersome when text is mixed with your code

Storing the texts in simple text files should be just fine for most applications. The only problem here could be when part of the application actually change the text. In these cases storing them in a database might be a good idea.

Storing text in database is overkill most of the time. A database mainly offers the benefit of ACID transactions and indexes on structured data. But if your texts don't change through the application the ACID properties aren't of much use. And if these are just text pieces to be used in the application, you'll be able to specify the name of the piece/file directly, so indexing as done by the data doesn't do any good either. But a database has also costs: Large volumes of data might make the cache inefficient for the data which really belongs in the database. Transaction handling causes a performance hit. So if you don't have to, you shouldn't use a database.

---

If these files already exist, and can be expected to change later, it might be a good idea to reference them from the database by filename.

If, on the other hand, you want the text itself to live in the database, then having a table of "page content" could work well with each tuple representing a separate text: one attribute being an identifier for the text, one attribute being the full text itself.

Whichever you choose, I'd recommend to follow the DRY principle: choose one canonical easily-managed location and stick to that throughout the application.