Hi Damien,
We are obviously all fans of SQLite and keen to involve more people in
what is one of the best DB systems in existence and most widely used DB
in the World.
But...
SQLite answers a need that is quite specific (though widely used) in
that it is very small, very fast and, as a bonus, can be compiled right
into most software projects so distribution is not an issue - which
further means it is also server-less. This last feature makes it
specifically not well suited for large network-server and service type
applications and not well suited for user control. Encryption is easy
(as others explained) but your replies indicate you are more interested
in user control. While some extensions do exist to allow a form of user
control, I think what you really want is called PostGres or Maria-DB
(previously MySQL). They are equally free, open-source, they support
client-server architecture and both storage-encryption and user-control
are inherent to these systems, and they play very well with web-script
engines (such as PHP and its ilk).
Use SQLite for local storage that need not be protected from users with
access to the local file system. Store all your application settings in
SQLite, etc. It is not uncommon to use multiple database engines in a
single project. Right tool for the job and such.
Of the two alternate engines above, my preferred is PostGres, but there
are situations where Maria DB works a treat (such as the usual
LAMP-stack quick web-server solutions and the like) and it has some easy
and strong scripting capabilities.
Links:
https://mariadb.org/
https://www.postgresql.org/
Good luck,
Ryan
On 2016/10/08 9:18 AM, Damien Sykes-Lindley wrote:
Hi Darren,
You are correct in that genealogy is generally public. However more
often than not the information you want to publish may very well
differ from what is in your private database. You may have private
notes telling you what you need to do. You may have anecdotes shared
by many family members that may need to be kept private, at least
until the involved parties are deceased or otherwise choose to divulge
it publicly themselves.
Even more importantly I may choose to add an address-book style
feature in there so you can easily group and contact appropriate
family members for whatever reason (special occasions etc). Of course
that will be private.
Password protecting it is also good on many levels - if the database
is to be used online then it is needless to say that authentication
would be required for various people to view it. Even if I decide to
make it local only, there is the possibility that anyone sharing the
computer or network may peruse the database when you don't want them to.
Kind regards,
Damien.
-----Original Message----- From: Darren Duncan
Sent: Saturday, October 08, 2016 6:54 AM
To: SQLite mailing list
Subject: Re: [sqlite] Protecting databases
On 2016-10-07 10:46 PM, Damien Sykes-Lindley wrote:
Hi there,
My name is Damien Lindley, and I am, among other things, an
independent, hobbiest programmer. I have been blind since birth and
thus all my computer work relies on screenreader software and keyboard.
I have only just come through the brink of scripting into compiled
programming and so I guess I am still a beginner in many respects.
However I don’t work in C or C++, so most of my programming, if using
a library, relies on precompiled static or dynamic libraries. Or of
course libraries that are written or converted specifically for the
language I work in (FreeBASIC).
Recently, I decided I needed to create a piece of software that could
manage family trees, since there seems to be a lack of screenreader
accessible genealogy managers out there. I was advised the best way
to do this is to use a database engine. I was also informed that
SQLite is always a good choice for databases.
I must admit, I have never worked with databases before and so now I
am in the process of learning SQL. However looking at the programming
API for SQLite I cannot see any means of password protecting the
database without either buying a commercial extension to do this, or
recompiling SQLite with the authentication extension. Due to
financial constraints and unfamiliarity with compiling in C both of
these are not an option for me. Also I need a secure way to do this,
as I think I read that the SQLite version simply uses a table to
store the user data, which of course can be read and accessed elsewhere.
Are there any other options available for doing this?
Any help appreciated.
Thanks.
Damien.
Damien,
Why do you need to password protect the database?
Genealogy information is generally of the public record variety so
there is
nothing sensitive to protect. I am making genealogy software myself
and so am
familiar with many of the relevant issues.
I would say please explain why you think you need password protection
for this
project and then the real issue at hand can be addressed.
If yours is a network application and you don't want people on the
open internet
from accessing the database, fair enough, but that's an application-level
solution; what you're asking for here is that people who have direct
access to
the SQLite database file are blocked by a password, and this I question.
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users