[lug] Which Database schema?

[BC]

On 11/13/2018 4:25 PM, Bear Giles wrote:
> > In the meantime I'll leave it asa 55 columns each containing the 
> same, native fields for differentweeks/yr.
>
> Eek!
>
> You still want to normalize your data. If absolutely necessary you 
> can create a view that does stuff like this.
>
> The question on whether to split names and addresses into components 
> is actually pretty deep. Besides the problems that are obvious to us 
> in some countries you can have more than one legal name, e.g., you 
> might have different names in different character sets. Or you might 
> have different names for different purposes or at different times 
> (e.g., how people often change their name here at marriage.) In this 
> case you want to keep it as abstract as possible modulo business 
> needs. E.g., many sites want it split out because they send the 
> information to an address verification webapp.
>
> But ironically that's also an increasingly moot point since privacy 
> practices would require the information to be encrypted anyway. The 
> best way to handle that is to create a 'wallet' (name-value pairs), 
> encrypt that, and then store that encrypted value in the database. 
> You can expose bits for searchability, e.g., first three letters of 
> last name, last four of credit card number, everything but the 
> address1 and address2 lines for the address. But with best practices 
> name, email address, street address, etc., should be encrypted no 
> matter how small your database or app.

Ooooops. I totally overlooked doing this. Thanks for reminding me to 
look into it.

And all the other good items you mentioned above as well. I'm sure 
glad I asked my original question in order to get this info as well...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20181113/4bc3c5da/attachment.html>