On Tue, Feb 24, 2009 at 3:24 AM, leledumbo <leledumbo_c...@yahoo.co.id> wrote:
> Just tried serializing array of 256 booleans and printing the length, it
> really shocked me: 2458. This project will be used by about 500 students, so
> in the worst case (all students enroll all courses) it will eat 500 * 2458
> (assuming one character eats one byte) = 1229000 Bytes ~= 1.2 MB. Not a big
> deal, eh?
That is a very un-normalized way of storing associations between
entities in a database. You describe a "worst case scenario" where
every student is registered for every course. If you serialize an
array, every bit takes the same amount of space so it doesn't matter
how many courses each student has. If you convert this to a bitmask as
you are describing, your worst case would happen very frequently - at
least as often as students are assigned to the course whose place is
the most significant bit value. What's more, if you later need to add
a 257th course, you could have lots of work to do to adjust your code
to deal with the extra value.
Generally relationships like the one you describe are stored in three
separate and related tables: Students, Courses, and Enrollment. The
latter is a n:m association between the first two. The advantage this
approach has with regard to storage is that it is a sparse matrix.
Most students will only enroll in a handful of courses. With this
approach, you only store a row in the Enrollment table if a student is
enrolled in a course. Otherwise, you don't need to store anything.
Granted, if you use 4-byte integers for the primary keys in both the
Students and Courses tables, your data storage would be about 2048
bytes for the data "worst case scenario" that you described, and
another 2048 bytes for a unique index that would insure that each
student could be enrolled in any course no more than one time.
However, since I highly doubt most students are going to be enrolled
in every course, it is not likely that you'll approach the 1.2MB
storage space that you're worried about. Each row would take 16 bytes
to store both the data and the index; if each student is enrolled in
an average of 4 courses, it should only take an average of 64 bytes
per student. For 500 students, that works out to around 2000 rows at
about 32KB overall.
For comparison, I have a fairly small table in a system we recently
put into production that maintains similar associations. It stores
more information in each row than just a two-column association (about
17 columns) and currently has over 7400 rows. The data is 0.734MB and
the total size of three indexes is 0.820MB.
And no, 1.2MB is not that big of a deal. A single floppy high-density
drive could hold that much data 18 years ago!
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php