<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Managing LARGE Databases Continued</title>
	<atom:link href="http://pthree.org/2006/01/26/managing-large-databases-continued/feed/" rel="self" type="application/rss+xml" />
	<link>http://pthree.org/2006/01/26/managing-large-databases-continued/</link>
	<description>Linux.  GNU.  Freedom.</description>
	<lastBuildDate>Mon, 17 Jun 2013 17:06:01 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.6-beta3-24432</generator>
	<item>
		<title>By: Aaron</title>
		<link>http://pthree.org/2006/01/26/managing-large-databases-continued/#comment-988</link>
		<dc:creator>Aaron</dc:creator>
		<pubDate>Wed, 12 Jul 2006 16:40:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2006/01/26/managing-large-databases-continued/#comment-988</guid>
		<description><![CDATA[Dan-

I just used the import feature.  I don&#039;t know the exact steps, but importing a dBase 5 table with 256 fields and literally millions of rows takes easily an hour.  I was told by a Microsoft developer that the reason for this is SQL Server is mapping many more field types to every record than dBase 5 supports.  For example, in dBase, it is either a number (int) or float.  But in SQL Server, it could be a short, int, long, double or float.

Eventually, I abandoned SQL Server for MySQL.  It can import a dBase 5 table of that size in 10-15 minutes, which is much much faster than SQL Server 2000.  And, being the FOSS advocate that I am, it follows my beliefs and principles, where proprietary software such as SQL Server 2000, does not.  MySQL also does everything I need, plus much much more.  I love it!]]></description>
		<content:encoded><![CDATA[<p>Dan-</p>
<p>I just used the import feature.  I don&#8217;t know the exact steps, but importing a dBase 5 table with 256 fields and literally millions of rows takes easily an hour.  I was told by a Microsoft developer that the reason for this is SQL Server is mapping many more field types to every record than dBase 5 supports.  For example, in dBase, it is either a number (int) or float.  But in SQL Server, it could be a short, int, long, double or float.</p>
<p>Eventually, I abandoned SQL Server for MySQL.  It can import a dBase 5 table of that size in 10-15 minutes, which is much much faster than SQL Server 2000.  And, being the FOSS advocate that I am, it follows my beliefs and principles, where proprietary software such as SQL Server 2000, does not.  MySQL also does everything I need, plus much much more.  I love it!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan</title>
		<link>http://pthree.org/2006/01/26/managing-large-databases-continued/#comment-974</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Tue, 11 Jul 2006 11:26:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2006/01/26/managing-large-databases-continued/#comment-974</guid>
		<description><![CDATA[How did you get your data in to the SQL server?

Using a DTS package direct copy is in my experience the fastest way to batch load your database and it can process 100&#039;s of thoughsands of records rapidly. 

Of course this does depend on your table structure e.g. A triggers, indexes , etc will slow it down.

Have you tried Oracle (the free version... unless you&#039;re gonna splash out)?]]></description>
		<content:encoded><![CDATA[<p>How did you get your data in to the SQL server?</p>
<p>Using a DTS package direct copy is in my experience the fastest way to batch load your database and it can process 100&#8242;s of thoughsands of records rapidly. </p>
<p>Of course this does depend on your table structure e.g. A triggers, indexes , etc will slow it down.</p>
<p>Have you tried Oracle (the free version&#8230; unless you&#8217;re gonna splash out)?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jordy</title>
		<link>http://pthree.org/2006/01/26/managing-large-databases-continued/#comment-49</link>
		<dc:creator>jordy</dc:creator>
		<pubDate>Tue, 31 Jan 2006 17:07:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2006/01/26/managing-large-databases-continued/#comment-49</guid>
		<description><![CDATA[I think the goal to compete with Access is a noble one.  I&#039;ll probably still use Postgress myself, but there is major demand for an open source Access killer.  The open sourceness of it will make it not suck eventually, it just needs a little time.]]></description>
		<content:encoded><![CDATA[<p>I think the goal to compete with Access is a noble one.  I&#8217;ll probably still use Postgress myself, but there is major demand for an open source Access killer.  The open sourceness of it will make it not suck eventually, it just needs a little time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben</title>
		<link>http://pthree.org/2006/01/26/managing-large-databases-continued/#comment-42</link>
		<dc:creator>Ben</dc:creator>
		<pubDate>Thu, 26 Jan 2006 16:22:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.pthree.org/2006/01/26/managing-large-databases-continued/#comment-42</guid>
		<description><![CDATA[Base is supposed to compete against MS Access; it sounds like it has similar limitations as far as scalability and thus it comes as no big surprise that it doesn&#039;t measure up against Paradox, SQL Server, MySQL, etc. 

You should try SqlLite - it is small and VERY fast. Not as robust as MySql, but it sounds like it may be better for what you are trying to do. Give it a try.]]></description>
		<content:encoded><![CDATA[<p>Base is supposed to compete against MS Access; it sounds like it has similar limitations as far as scalability and thus it comes as no big surprise that it doesn&#8217;t measure up against Paradox, SQL Server, MySQL, etc. </p>
<p>You should try SqlLite &#8211; it is small and VERY fast. Not as robust as MySql, but it sounds like it may be better for what you are trying to do. Give it a try.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
