Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The strings are, on average, 300 characters each. That's either 300 or 600 bytes, depending on Unicode settings. Let's say you use a <code>varchar(4000)</code> column and use (on average) 300 bytes each.</p> <p>Then you have up to 200,000 of these to store in a database.</p> <p>That's less than 60 MB of storage. In the land of databases, that is, quite frankly, peanuts. 60 <strong>GB</strong> of storage is what I'd call a "medium" database.</p> <p>At this point in time, even <em>thinking</em> about compression is premature optimization. SQL Server can handle this amount of text without breaking a sweat. Barring any system constraints that you haven't mentioned, I would not concern myself with any of this until and unless you actually start to see performance problems - and even then it will likely be the result of something else, like a poor indexing strategy.</p> <p>And compressing certain kinds of data, especially very <em>small</em> amounts of data (and 300 bytes is definitely small), can actually sometimes yield worse results. You could end up with "compressed" data that is actually larger than the original data. I'm guessing that most of the time, the compressed size will probably be very close to the original size.</p> <p>SQL Server 2008 can perform page-level compression, which would be a somewhat more useful optimization, but you're on SQL Server 2005. So no, definitely don't bother trying to compress individual <em>values</em> or <em>rows</em>, it's not going to be worth the effort and may actually make things worse.</p>
    singulars
    1. This table or related slice is empty.
    1. PODealing with large number of text strings
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USAaronaught
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODealing with large number of text strings
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO+1 Thanks for the explanation. Like I said, this is only a part of the requirement, my overall data stored is much larger than that. Plus, this is per-run, 60MB, so it wouldn't take too long to fill up 60GB or even TB. At this stage, this program is intend to run very often. One of the answer has suggested SQL 2008 compression, but it is limited to Enterprise and Developer edition. Also after I read the details, the compression mostly turn fixed length data into variable length so wouldnt help me much as I already do that.
      singulars
      1. PO
      1. USFadrian Sudaman
    2. CO@Fadrian: Even if you got, say, a generous 60-70% compression level out of SQL '08 page compression (which you don't have access to), that's not really going to change the big picture. If it's filling up into the TB range then I would start to question how much of the data you really need stored permanently. I can't imagine what one would be doing with 10 TB of plain text...
      singulars
      1. PO
      1. USAaronaught
    3. COTotally agree. I do have some smart in the application to not store duplicates to again reduce the storage and hopefully TB storage is more than sufficient and wont go into TBs. Part of the problem is that the project I'm building is modelling evolution data and hence historical data are a main part of my domain model and dealing with large storage is one of its major challenge.
      singulars
      1. PO
      1. USFadrian Sudaman
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload