--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-785B2F0B-E7E6-5DAE-98F1-6C32BED25964.dita Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept xml:lang="en" id="GUID-785B2F0B-E7E6-5DAE-98F1-6C32BED25964"><title>Database storage overhead</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>Space utilization is efficient</p> <ul><li id="GUID-8AE05C00-0C7E-5D9C-AC2B-DC1D5432DF0D"><p>the underlying permanent file store adds minimal overhead to maintain its structure: store imposes a fixed 46 bytes + 2 bytes per additional 16K; each stream requires 7 bytes.</p> </li> <li id="GUID-5BDB30B0-9140-55AA-A7BE-4C4B30355ADE"><p>the database has minimal space requirements to store its schema and data structure.</p> </li> <li id="GUID-3FCF5F99-767F-5526-B0AF-40F7F248CF26"><p>including the stream overhead, row storage overhead can be less than 2 bytes per row in ideal clustering conditions, even with lower clustering the overhead is usually below 1% of the data volume.</p> </li> </ul> <p>The storage required for a row can be determined as follows:</p> <ul><li id="GUID-41E7E40C-6E34-5C7A-BB82-A0AF92B5D455"><p>each non-null value requires the storage for fixed width columns, and the raw storage plus 1 byte for variable width columns.</p> </li> <li id="GUID-845C1A45-8C1F-5EA0-A3A6-787359332505"><p>long columns are stored embedded in the row data when they are small enough, and otherwise they are stored in a separate stream: this makes more efficient use of the both space and speed. When embedded they require just 1 bit more than the short columns, when separated they require 8 bytes in the row data plus any stream overhead.</p> </li> <li id="GUID-CD64205E-894B-50D3-9AAA-ACA375D820EA"><p>each nullable column requires an extra 1 bit.</p> </li> <li id="GUID-4FF233BB-3863-5869-9E6E-E56AC3B29924"><p>bits are packed into bytes in the row storage.</p> </li> </ul> <section><title>Indexes</title> <p>Indexes are implemented using STORE B+trees. Note in particular that indexes use fixed length keys, so that indexes on longer text fields can consume significant space.</p> <p>If the key for the index is <i>k</i> bytes, the number of rows to index is <i>n</i>, the index page size is <i>P</i>, and the B-tree packing density is <i>r</i>:</p> <p><i>a = [(P-8)/(k+4)] * r</i> </p> <p>Where <i>[x]</i> is the largest integer <= <i>x</i>. Then the number of pages required, <i>N</i>, is</p> <p><i>N = n * (1/a + 1/(a*a))</i> </p> <p>Each page requires <i>P+7</i> bytes in the store, so the total indexing overhead, <i>S</i>, is</p> <p><i>S = N * (P+7)</i> </p> <p>For DBMS <i>P=512</i> and <i>r=0.86</i>.</p> </section> </conbody></concept>
\ No newline at end of file