<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I rewrote the schema and and installed
      it on the MariaDB server. I attached the schema to this email. I
      didn't make a user or grant privileges to a non-root user yet
      because I don't know what user is going to need to read it yet
      because I don't anything about the PHP application that is going
      to read or write to it. <br>
      <br>
      I realized that sense we are using <span dir="auto">surrogate
        keys it would be efficient to find the email address via the
        join on renewal(contact_id) because it would be related to
        exactly to one email address. The email address can change
        without having a cascade update.</span><br>
      <br>
      In either case, it is time for the PHP part now.<br>
      <br>
      On 12/31/2014 07:47 PM, John Lewis wrote:<br>
    </div>
    <blockquote cite="mid:54A4992E.3040600@gmail.com" type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=windows-1252">
      <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 moz-do-not-send="true" 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">
        <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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:wplug-internet@wplug.org">wplug-internet@wplug.org</a>
<a moz-do-not-send="true" 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>
    </blockquote>
    <br>
  </body>
</html>