<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">There is not really a good reason to
      use SQLite3 in production when we already have a perfectly good
      database server running.<br>
      <br>
      I am developing the initial schema in SQLite3 because there is a
      lower barrier of entry for setting up an SQLite3 datatabase than a
      MariaDB database, so we can develop and test a workable schema
      faster without needlessly putting the production database server
      at risk. I never suggested using it instead of MariaDB and was
      always was planning to rewrite the schema once we agreed to a
      database design.<br>
      <br>
      I have yet another new schema attached to this email.<br>
      <br>
      If you have an integer as a primary key and don't populate it,
      SQLite3 assumes you want an auto-incrementing primary key.<br>
      <a class="moz-txt-link-freetext" href="https://www.sqlite.org/autoinc.html">https://www.sqlite.org/autoinc.html</a><br>
      <br>
      <br>
      <br>
      On 12/31/2014 12:23 PM, Joe Prostko wrote:<br>
    </div>
    <blockquote
cite="mid:CAKfvZxxS9J92d8RaCkfa0tcyRzh8h7zS5XQBD=Qu7cXGQc_P-g@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>
          <div>On Wed, Dec 31, 2014 at 6:34 AM, John Lewis <<a
              moz-do-not-send="true" href="mailto:oflameo2@gmail.com"
              target="_blank">oflameo2@gmail.com</a>> wrote:<br>
            <br>
            > That said I don't think it is a good idea to reduce
            this to just one<br>
            > table because Just as Pat said there is no guarentee
            that every contact<br>
            > has a membership associated with them.<br>
            <br>
          </div>
          <div>Using multiple tables does likely make more sense, simply
            because we may make other categories of users and be
            tracking things outside of membership.  It's probably better
            to plan ahead for such a thing instead of having to worry
            about overhauling things at a later day due to a choice that
            was too constraining (and would result in an unmanageable
            amount of columns).  That said, a single table could still
            easily work for the current use case with proper WHERE
            clause logic (checking for NULL/IS NOT NULL values in
            certain column(s), or checking a column that flags if
            somebody is a member or not, for instance).  I suppose it
            could get trickier if somebody was a former member though,
            as you would then have to do date comparisons (MySQL makes
            that easy though), or else rely on the binary flagging
            method.<br>
          </div>
          <div><br>
          </div>
          <div>In any case, two tables definitely works, so let's do
            that.  :)<br>
          </div>
          <div><br>
            > I see if I can make a database in sqlite3 that auto
            creates an auto<br>
            > incrementing primary key. If I can and it make sense, I
            will post it<br>
            > here. Then I will rewrite it for mariadb, post that
            here and then commit<br>
            > it to <a moz-do-not-send="true"
              href="http://wplug.org" target="_blank">wplug.org</a>'s
            mariadb so we can move on to the PHP part so we can<br>
            > finish a project. I can go ahead and prepopulate the
            database with all<br>
            > of the data from the spreadsheet if requested.<br>
            <br>
          </div>
          Honestly, we could simply use SQLite for this, most likely. 
          It seems we have the necessary PHP modules already enabled
          from my quick check.  I usually use MySQL (or variants like
          MariaDB or Percona), simply because phpMyAdmin is such a nice
          tool for those times when you don't want to mess around with
          the DB directly.  I don't think we actually have it installed
          though, so using SQLite would be just as easy, currently. 
          Database backups would be easy too, for obvious reasons.  I
          guess it depends if we'd like to integrate this fully with the
          wiki or not, or if we want to it to act more standalone.<br>
          <br>
        </div>
        - joe<br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
wplug-internet mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wplug-internet@wplug.org">wplug-internet@wplug.org</a>
<a class="moz-txt-link-freetext" href="http://www.wplug.org/mailman/listinfo/wplug-internet">http://www.wplug.org/mailman/listinfo/wplug-internet</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>