I run a Drupal 5 site with just under a half million nodes on a single
$50 VPS. As long as you don't run any stupid queries, you're fine.
That said, you can integrate Views to any arbitrary SQL table. You just
need to write the views_data hook for it. There is, or was at least, a
module to help automate that process.
The deciding factor for node-or-not is not the volume of data, but how
it will be maintained. Do you want each of those records to have its
own view page, edit page, workflow, etc. within Drupal? Make 'em a
node. Is it legacy read only data that will never be updated by a
human? Probably not worth the effort to make them nodes.
--Larry Garfield
On 3/8/12 11:35 AM, Cameron Eagans wrote:
Drupal.org is also running on a cluster of servers that have been scaled
over a longer period of time by people that know what they're doing.
On Mar 8, 2012 8:08 AM, "Ms. Nancy Wichmann" <[email protected]
<mailto:[email protected]>> wrote:
Let's see, Drupal.org has more than 10 times the nodes plus many
more comments. It runs D6 and uses Views. And it is usually fast enough.
/*Nancy*/
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin
L. King, Jr.
------------------------------------------------------------------------
*From:* Sam Cohen
The client currently has a searchable database of a 115,000
records written in cold fusion in a separate database on a
separate server.
They would like me to bring it into their Drupal 6 site or at
least onto the same server.
I can do this in two ways:
1. As a custom module running off it's own db.
2. Or I can make it a content type and use Views for the
interface.
My preference is to just use CCK/Views for maximum flexibility
-- but I question whether or not it's wise to add a 115k records
to the node and other tables and what type of impact this might
have on overall site performance. (Any other downsides?)
Anyone have any advice/suggestions? If it was your project
would you code it separately or use CCK/Views.
