<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I think it all depends on use case, amount of expected traffic, and
    how much dev time you want to throw at the problem.<br>
    <br>
    My first thought would be to just use a Migrate migration script or
    Feeds to pull them into Drupal as nodes, and let Solr index them.
    200k nodes is not a *huge* amount. Drupal should handle it just
    fine. Feeds might be better in this case if the external dataset
    might continue to grow or be updated.<br>
    <br>
    Alternatively, you could write a custom module to provide CRUD
    functions against the external DB, and write some Solr indexing code
    to handle indexing the external DB. Then you can set up a second
    Solr search environment to search against the external DB without
    pulling it into Drupal at all. This might be higher performance,
    once again depending on your site / use case / user patterns.<br>
    <br>
    If running Solr is not an option, you might be in for some pain. The
    core search doesn't necessarily handle large node count use cases
    particularly well.<br>
    <br>
    Brian<br>
    <br>
    On 12-05-01 09:25 AM, Sam Cohen wrote:
    <blockquote
cite="mid:CAGrS=KWrtp=cOGJv6BbwUS2r3PxnnJE+NPwa7jQNg_vhj1XpsQ@mail.gmail.com"
      type="cite">This list has sure gone quiet lately.&nbsp; Is everyone
      just so busy with work?<br>
      <br>
      (Sorry if this isn't the place to ask this.&nbsp; If anyone knows a
      better place, please advise. )<br>
      <br>
      A client of mine with a Drupal site I inherited wants to bring in
      a very large database into their site.&nbsp; It's basically over
      200,000 genealogical/cemetery records that need to be searchable
      by users.&nbsp;&nbsp; I'm struggling over whether to do it (1) as a custom
      module, with it's own separate database or (2) to do it with
      views/content type and node import.&nbsp; The client also needs to be
      able to edit the records through the site.&nbsp; <br>
      <br>
      The latter approach would be quicker to set up, but I worry that
      it would bloat the site, potentially cause performance issues, and
      perhaps other problems I'm not thinking about.&nbsp;&nbsp; <br>
      <br>
      It's a D6 site for a relatively small nonprofit without a lot of
      traffic.<br>
      <br>
      How would you handle it?&nbsp; Custom module or content type/Views?<br>
      <br>
      Thanks,<br>
      Sam<br>
      <br clear="all">
      Sam Cohen, Principal<br>
      <a moz-do-not-send="true" href="http://new-media-solutions.com"
        target="_blank">New Media Solutions</a><br>
      Drupal Training &amp; Services<br>
      <i><a moz-do-not-send="true"
          href="http://new-media-solutions.com/drupal-training"
          target="_blank">New Courses Starting Soon</a></i><br>
      <br>
      <div style="display:inline">
      </div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
consulting mailing list
<a class="moz-txt-link-abbreviated" href="mailto:consulting@drupal.org">consulting@drupal.org</a>
<a class="moz-txt-link-freetext" href="http://lists.drupal.org/mailman/listinfo/consulting">http://lists.drupal.org/mailman/listinfo/consulting</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>