OT: Database software

Post by Ken Springer
Looking for recommendations for database software.
Relational would be nice, but not mandatory. Simpler, and easier to
learn and use than Access. I've never tried Paradox, part of Corel Office.
I need more than using a spreadsheet can provide.

Such as what? If we know what you _do_ want (or would like), we'll
probably be able to advise better.

(Do you actually need to do _sums_ on the entries anyway? If not, you
don't need a _spreadsheet_ as such at all, though it may be that the
majority of databases give that almost by default. I mention it only
because a lot of people think "spreadsheet" when what they want is just
"table", and thus they use Excel - or one of its clones - when they
don't need it [and often given themselves problems by doing so]. But
since you've said database rather than spreadsheet in the first place,
this probably doesn't apply in your case.)

Post by Ken Springer
Open source would be my first preference, but not mandatory. I know
Libre Office and Open Office have Base, but my impression is that
program is in the Access category of software.

By category I presume you mean difficulty (to learn) level.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

I have never liked children, even when I was one.
- Miriam Margolyes (RT 2014/11/1-7)

Ken Springer

2018-06-04 00:07:03 UTC

Such as what? If we know what you _do_ want (or would like), we'll
probably be able to advise better.

It should be nothing more than simple data tracking, but I don't know
what the future will be. It's possible a lot of text for a single field
in each record, which I find to be a PITA in a spreadsheet field.

Post by J. P. Gilliver (John)
(Do you actually need to do _sums_ on the entries anyway?

I shouldn't. At most I expect to need nothing more than how many
records reflect this concern, how many reflect that concern, etc.

A non-relational database would work, just trying to avoid repetitive
input of the same info, such as a person's name.

Post by J. P. Gilliver (John)
If not, you
don't need a _spreadsheet_ as such at all, though it may be that the
majority of databases give that almost by default. I mention it only
because a lot of people think "spreadsheet" when what they want is just
"table", and thus they use Excel - or one of its clones - when they
don't need it [and often given themselves problems by doing so].

Are you using "table" to mean tables you find in word processors?

Post by J. P. Gilliver (John)
But
since you've said database rather than spreadsheet in the first place,
this probably doesn't apply in your case.)

For non-relational databases, Database Oasis
(https://databaseoasis.com/Default.aspx) is probably overkill for what
my anticipated needs are, and it used to be a lot cheaper. I
experimented with it for a project a number of years ago, but report
limitations knocked it out of the running.

By category I presume you mean difficulty (to learn) level.

That, and the complexity of operations you can perform with it. Back in
my 8-bit days, I had a couple of databases that would do what I want at
this point.

But... I don't want to start out with something too simple, and find
out in 3 months (for example) that something comes up that the program
can't do, and I essentially have to start over.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

mick

2018-06-04 22:03:02 UTC

Such as what? If we know what you _do_ want (or would like), we'll
probably be able to advise better.

It should be nothing more than simple data tracking, but I don't know what
the future will be. It's possible a lot of text for a single field in each
record, which I find to be a PITA in a spreadsheet field.

You could put a hyperlink in a spreadsheet cell to an external text
file, document, pdf or such like if the data seems too overwhelming for
the single cell. Even in a database it may still be prudent to do
that.

--
mick

Mayayana

2018-06-04 22:22:48 UTC

"mick" <***@junk.mail> wrote

| You could put a hyperlink in a spreadsheet cell to an external text
| file, document, pdf or such like if the data seems too overwhelming for
| the single cell. Even in a database it may still be prudent to do
| that.
|

MSIs can store a binary data type that's just
a stream of bytes and can be text or binary file
data, with no size limit that I know of. It seems
that SQL databases can also store large data,
as either character or binary. I don't know anything
about Access, but I assume that can also do it.

There's no reason that large data storage should
be a problem.

One could even create a primitive, text-based
database, store binary data as base64, and store
all of that in a simple text file. I have a customer list
database I made that holds about 800 entries and
just separates each 1-line entry with ***. It's fast
and easy. I made it that way because I just didn't
need the capacity that a more sophisticated database
could handle. Programmatic methods to search a string
are so fast that it would be very much feasible to
store large strings for each entry and still get
fast operation. And that's not even getting the
advantage of random access seek.

mick

2018-06-04 23:56:59 UTC

Post by Mayayana

Post by mick
You could put a hyperlink in a spreadsheet cell to an external text
file, document, pdf or such like if the data seems too overwhelming for
the single cell. Even in a database it may still be prudent to do
that.

MSIs can store a binary data type that's just
a stream of bytes and can be text or binary file
data, with no size limit that I know of. It seems
that SQL databases can also store large data,
as either character or binary. I don't know anything
about Access, but I assume that can also do it.

This reply is solely about Microsoft Access as a user.
Access does not like photos being stored in the database.
I tried it once in my customer database and it slowed it down.

Text data should not be a problem, but what I was perhaps alluding to
was that many pages of text maybe more suitably produced and formatted
in a word processor and a link made to the saved file, rather than
entering the text solely in the database. Yes, you could copy and
paste the text into the database but you can only format it once it is
in there when it is in table view, you cannot do it in a form view.

It is not usually desirable to be entering data in a table, especially
if more than one person is entering the data, maybe ok for a sole owner
to do it, put even I as a sole user always enter data using forms.
Scrolling across large tables to find the correct column to input data
is mind numbingly awkward, hence the use of forms where completely new
data is easily added or previous records can be updated with ease.

--
mick

Mayayana

2018-06-05 02:49:22 UTC

"mick" <***@junk.mail> wrote

| Text data should not be a problem, but what I was perhaps alluding to
| was that many pages of text maybe more suitably produced and formatted
| in a word processor and a link made to the saved file, rather than
| entering the text solely in the database. Yes, you could copy and
| paste the text into the database but you can only format it once it is
| in there when it is in table view, you cannot do it in a form view.
|

I don't understand "form view". I'm afraid my experience
is limited and atypical. I've created databases for my own
purposes and usually make my own frontend. Maybe the front
end is what you mean by "form"?

I've never actually entered all the data from scratch. I
use scripts. For instance, when I decided to put all my past
email in a database I used scripts to automate loading the
emails into MSIs named Inbox, Sent, etc, with a single
table containing columns for key number, To, From, Date,
Year, Subject, Keywords, and a binary column to store
the entire email. That allows me to also retrieve attachments
if desired. So I'm not accessing large text fields or binaries
as table fields directly. I'm storing and accessing that data
in fields but retrieving it into a GUI, in a usable form.

Then I wrote an HTA to load those MSIs, search, display,
edit, etc. It's hard to imagine a database where I might
enter each row, one at a time. Even if that much is automated
it would be a big job.

Similarly, when I wanted a ZIP code database and when
I wanted a geolocation <-> IP database, that entialed 10s
of thousands of entries. I created them by using script
to format a CSV file and then using another script to nter
the CSV lines into an MSI table. That kind of thing
wouldn't be worth doing by hand.

But I suspect I'm missing a big chunk of info about this
kind of thing as I've never used databases professionally
and never used MS Office to speak of. So I don't know
how the typical person uses them and what they need
in terms of features. It sounds like you're saying that
Access "forms" are a customizable GUI front-end option.

Ken Springer

2018-06-05 03:16:01 UTC

Post by Mayayana
| Text data should not be a problem, but what I was perhaps alluding to
| was that many pages of text maybe more suitably produced and formatted
| in a word processor and a link made to the saved file, rather than
| entering the text solely in the database. Yes, you could copy and
| paste the text into the database but you can only format it once it is
| in there when it is in table view, you cannot do it in a form view.
|
I don't understand "form view". I'm afraid my experience
is limited and atypical. I've created databases for my own
purposes and usually make my own frontend. Maybe the front
end is what you mean by "form"?

If I understand Mick correctly, "form view" is what the user would see
to enter data into. The data then populates a new row of cells, in this
case a spreadsheet.

It avoids having to scroll across number screens of cells for each row,
just to enter all the data.

Think of going to a new website, and you have to register with name and
whatever. That screen you see is the form view. And behind the scenes,
the data is going into the database itself.

In Access, the data in the "form" is entered into a table, which
visually looks like a spreadsheet, with rows and columns, but that table
is just a data "holder" for lack of a better word.

I did that 20 years ago for my inlaws, using Access 97. That was my
last use of Access.

In my case, the one that prompted this thread, each record will be new
to me, nothing will come from information I already have.

<snip>

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-05 12:46:50 UTC

"Ken Springer" <***@greeleynet.com> wrote

| If I understand Mick correctly, "form view" is what the user would see
| to enter data into. The data then populates a new row of cells, in this
| case a spreadsheet.
|
| It avoids having to scroll across number screens of cells for each row,
| just to enter all the data.
|

OK. That's what I was guessing -- that Access provides
a way to create a ustom, rudimentary front-end to use
the database without needing to write software or
something like an HTA.
(That's what I mean by "front-end". The GUI for using
the database.)

| In my case, the one that prompted this thread, each record will be new
| to me, nothing will come from information I already have.
|

So you need a "form" of some kind but you don't
need any automated filling of tables? But you don't
know any programming or scripting and don't want
to tackle that? So you need a program like Access
that's large-data-friendly, cheap or free, and
easy to learn?

I got curious and tried making a database in Libre
Office. It immediately complained that it couldn't
access the data source. What? I just started the thing.
where does it think a datasource might be? Then it
told me I couldn't proceed without Java. Nothing's
worth installing Java. I give up. :)

Ken Springer

2018-06-05 15:03:48 UTC

Post by Mayayana
| If I understand Mick correctly, "form view" is what the user would see
| to enter data into. The data then populates a new row of cells, in this
| case a spreadsheet.
|
| It avoids having to scroll across number screens of cells for each row,
| just to enter all the data.
|
OK. That's what I was guessing -- that Access provides
a way to create a ustom, rudimentary front-end to use
the database without needing to write software or
something like an HTA.

Yep, I think we're on the same page. I don't know what an HTA is, though.

Post by Mayayana
(That's what I mean by "front-end". The GUI for using
the database.)

That part I followed. LOL

Post by Mayayana
| In my case, the one that prompted this thread, each record will be new
| to me, nothing will come from information I already have.
|
So you need a "form" of some kind but you don't
need any automated filling of tables?

I'm reading "automated filling of tables" to mean I already have the
data I want in the database available to me and I want to import the
data. The answer is no. There is no prior existing data that needs to
go into the database.

One thing Access can do is automatically populate a field with previous
data when you are manually inputting the data. So, if in FieldB you
entered the word "circus" in the record, when you go to the next
new/empty record, FieldB is automatically filled in with "circus", which
you can accept or type over.

Post by Mayayana
But you don't
know any programming or scripting and don't want
to tackle that? So you need a program like Access
that's large-data-friendly, cheap or free, and
easy to learn?

Correct. But, in this particular case, not necessarily large data
friendly. But, I'm looking at the possibility of using the program for
something else in the future, so the flexibility of having more data in
a new project is possible.

No, not interested in the programming and scripting. You like to make
the "tools" that you use. Which is cool, BTW. I just want to use the
tool you made, if it does the job I want to accomplish.

Sort of... We're both mechanics. You would build a ratchet to do the
job. I would buy the ratchet to do the job. <G>

Post by Mayayana
I got curious and tried making a database in Libre
Office. It immediately complained that it couldn't
access the data source. What? I just started the thing.
where does it think a datasource might be? Then it
told me I couldn't proceed without Java. Nothing's
worth installing Java. I give up. :)

Exactly what Nil was saying. And what my previous experiences have been
with Base when I tried it.

I had forgotten about Monobase from SSuite software until I just got a
newsletter from them a few minutes ago.
https://www.ssuiteoffice.com/categories/database.htm

I had tried figuring it out, but they had no help files. So I gave up.
But I just checked the site, and they now have some help files. So,
I'll take a look at it again, but for now I'm curious with what I can do
with a form in a spreadsheet. And, not Excel, if anyone is curious. <G>

And, it's free!

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-05 17:51:44 UTC

"Ken Springer" <***@greeleynet.com> wrote

| Yep, I think we're on the same page. I don't know what an HTA is, though.
|

Probably more than you care to know, but it might
be useful to some....

HTML Application. It's essentially IE with no security
restrictions. Name an HTML file to HTA and as long
as it's running locally (not online) you can do anything
you like with script and/or activeX controls. This is an
image of my MSI editor, which is written as an HTA.

Loading Image...

It's shown with a Microsoft MSI installer database
loaded.

The abilities of script in webpages are so vast that
it's possible to write something similar to fullscale,
compiled software as nothing more than a webpage
with script. The webpage is the interface for the
program and the script makes it work. Additionally,
scripting in Windows can use COM libraries. Simply
put, that means it can easily call outside components
to read/write files, automate MS Office, and even
use the built-in database options provided in Windows,
such as ADODB. The MSI tools I write as HTAs use the
COM interface of msi.dll, the Windows Installer library.

I often use HTAs because they're fun and relatively
easy to write, and the end-user can edit or customize
as desired. It's simpler than writing compiled software.

I especially find them useful for simple utilities and
database frontends because for that kind of thing,
textboxes, buttons and checkboxes are typically
all the GUI functionality that one needs. Storing data
and editing it in a systematic way is a relatively
simple task.

The MSI editor shown at the link uses nothing more
fancy than HTML tables to create a responsive database
table layout, with TD elements for the fields. Yet IE is
so fast and efficient that the editor can easily load
the 80+ tables of a typical installer MSI and switch
between table views almost instantly.

It's similar to what's beginning to be possible online,
but the online versions have taken a long time to develop,
using lots of little hacks, because security needs hobble
functionality. Better functionality has been available offline,
in HTAs, for 2 decades.

Microsoft created the HTA with
IE5. They very slowly realized that security online could
not co-exist with software-style functionality and
ActiveX controls, so with IE5 they began a slow move
toward beginning to think about maybe improving
security in IE. But lots of corporate people were using
IE to build in-house software in the form of webpages.
HTAs provided a way to improve IE security without
hobbling the ability to write "unsafe" webpage programs.

Steve Hayes

2018-06-06 02:39:35 UTC

On Tue, 5 Jun 2018 08:46:50 -0400, "Mayayana"

Yes, that is the problem with Libre Office.

It's not a stand-alone program, but requires something else to run.

There is SQLite, but it requires a front end written in some language
or other. Python does it, but then you have to have Python, like Java.

--
Steve Hayes
http://www.khanya.org.za/stevesig.htm
http://khanya.wordpress.com

mick

2018-06-05 14:57:35 UTC

If I understand Mick correctly, "form view" is what the user would see to
enter data into. The data then populates a new row of cells, in this case a
spreadsheet.
It avoids having to scroll across number screens of cells for each row, just
to enter all the data.
Think of going to a new website, and you have to register with name and
whatever. That screen you see is the form view. And behind the scenes, the
data is going into the database itself.
In Access, the data in the "form" is entered into a table, which visually
looks like a spreadsheet, with rows and columns, but that table is just a
data "holder" for lack of a better word.

Correct :-)

--
mick

Steve Hayes

2018-06-05 04:12:22 UTC

On Sun, 3 Jun 2018 18:07:03 -0600, Ken Springer

Such as what? If we know what you _do_ want (or would like), we'll
probably be able to advise better.

Post by J. P. Gilliver (John)
(Do you actually need to do _sums_ on the entries anyway?

I shouldn't. At most I expect to need nothing more than how many
records reflect this concern, how many reflect that concern, etc.
A non-relational database would work, just trying to avoid repetitive
input of the same info, such as a person's name.

I've used askSam and Inmagic, both non-relational text databases. The
Windows version of Inmagic, however, is prohibitively expensive, so I
continue to use the DOS Version. I'm not sure if askSam is still
available.

--
Steve Hayes
http://www.khanya.org.za/stevesig.htm
http://khanya.wordpress.com

Mayayana

2018-06-03 21:23:41 UTC

"Ken Springer" <***@greeleynet.com> wrote

| Looking for recommendations for database software.
|

A caveat: I don't have much need for database software,
so I don't know much about complex options. In the past
I've often not needed more than a searchable text file.

But I do use DBs a bit and when I do I use MSI
files. They use a simplified version of SQL that MS calls
"WQL". Samples here include a ZIP code lookup utility
and a code sample library:

https://www.jsware.net/jsware/msicode.php5

I made one recently to organize all of my stored email.
I typically design the database tables/columns for the
specific need and then make an HTA to use as a GUI
for it.

MSIs are supported with nothing extra on virtually
all Windows machines. And they're "robust". For instance,
I just loaded my "sent" email MSI into the HTA GUI,
with over 5,000 complete emails stored in it, taking
up 20+ MB. I then searched for a word in the email
content. It took about 3 seconds to find 106 emails
that contained that word.

That seems incredibly efficient to me, but it may
be that it's not so impressive next to fullscale SQL.
So I guess it might depend on what kind of scale
you need.

Ken Springer

2018-06-04 00:10:39 UTC

Post by Mayayana
| Looking for recommendations for database software.
|
A caveat: I don't have much need for database software,
so I don't know much about complex options. In the past
I've often not needed more than a searchable text file.
But I do use DBs a bit and when I do I use MSI
files. They use a simplified version of SQL that MS calls
"WQL". Samples here include a ZIP code lookup utility
https://www.jsware.net/jsware/msicode.php5
I made one recently to organize all of my stored email.
I typically design the database tables/columns for the
specific need and then make an HTA to use as a GUI
for it.
MSIs are supported with nothing extra on virtually
all Windows machines. And they're "robust". For instance,
I just loaded my "sent" email MSI into the HTA GUI,
with over 5,000 complete emails stored in it, taking
up 20+ MB. I then searched for a word in the email
content. It took about 3 seconds to find 106 emails
that contained that word.
That seems incredibly efficient to me, but it may
be that it's not so impressive next to fullscale SQL.
So I guess it might depend on what kind of scale
you need.

Hi, Mayayana,

I'm thinking this route may be something too involved, time wise, for me
to learn. The easier it is to get up and running is important, where
time is concerned.

But thanks for the suggestion.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-04 19:21:51 UTC

"Ken Springer" <***@greeleynet.com> wrote

| I'm thinking this route may be something too involved, time wise, for me
| to learn. The easier it is to get up and running is important, where
| time is concerned.

That may be, but if you don't come up with something
else, try the editor. It allows creating a database, opening it,
adding tables/rows/columns, editing values, etc. You don't
need to know much to set up a database. Any number of tables
can be created with any number of row fields, either 2-byte
integer or string up to 255 characters. You can also create
tables as tab-delimited text files and import them. Those can
then be searched via simple SQL-ish queries.

I've provided an editor front-end, a VBScript class to wrap
the complexity, and a similar ActiveX DLL that also wrap the
complexity. Between those options you can use pretty much
any tools to get at MSIs without a lot of research.

Where it does get more involved is if you want to do
more involved things like fields with different data types
or adding 1,000 rows programmatically. Then you'd
need to know a little about the SQL syntax (there's
an MSI help file) and you might need to know some
kind of scripting or programming language. Though I
assume you'd need that with any option. In other words,
if you want to do something like create a database of
500 people with their name, phone, address, etc and
also make it searchable, then you're going to have to
use some kind of programming or scripting tools to
automate that, even if it's just an automated script
to generate a CSV-type file for import.

Just an idea. As I said, I'm no expert on databases.
And I don't know what you need to do.

Ken Springer

2018-06-05 01:11:53 UTC

Post by Mayayana
| I'm thinking this route may be something too involved, time wise, for me
| to learn. The easier it is to get up and running is important, where
| time is concerned.
That may be, but if you don't come up with something
else, try the editor. It allows creating a database, opening it,
adding tables/rows/columns, editing values, etc. You don't
need to know much to set up a database. Any number of tables
can be created with any number of row fields, either 2-byte
integer or string up to 255 characters. You can also create
tables as tab-delimited text files and import them. Those can
then be searched via simple SQL-ish queries.
I've provided an editor front-end, a VBScript class to wrap
the complexity, and a similar ActiveX DLL that also wrap the
complexity. Between those options you can use pretty much
any tools to get at MSIs without a lot of research.
Where it does get more involved is if you want to do
more involved things like fields with different data types
or adding 1,000 rows programmatically. Then you'd
need to know a little about the SQL syntax (there's
an MSI help file) and you might need to know some
kind of scripting or programming language. Though I
assume you'd need that with any option. In other words,
if you want to do something like create a database of
500 people with their name, phone, address, etc and
also make it searchable, then you're going to have to
use some kind of programming or scripting tools to
automate that, even if it's just an automated script
to generate a CSV-type file for import.
Just an idea. As I said, I'm no expert on databases.
And I don't know what you need to do.

I'm no database expert either, but I do know not every database need
requires Access or other relational databases.

And finding info about non relational databases seems to be like
searching for hen's teeth.

As I mentioned earlier, I have used Database Oasis in the past, and it
was easy to use. But as I noted... The price has sure gone up.

I had completely forgot about forms in a spreadsheet. That might help a
lot, don't know at this point. I'll have to check the forms
capabilities of the spreadsheet I use, see what it can do. But, I'm not
terribly fond of the idea of an outside link to a file, when the file
isn't part of the main program. Knowing me, I might move the
spreadsheet and/or the external file(s), and break the whole darned
thing! LOL

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

mick

2018-06-05 14:55:27 UTC

I'm no database expert either, but I do know not every database need requires
Access or other relational databases.
And finding info about non relational databases seems to be like searching
for hen's teeth.
As I mentioned earlier, I have used Database Oasis in the past, and it was
easy to use. But as I noted... The price has sure gone up.
I had completely forgot about forms in a spreadsheet. That might help a lot,
don't know at this point. I'll have to check the forms capabilities of the
spreadsheet I use, see what it can do. But, I'm not terribly fond of the
idea of an outside link to a file, when the file isn't part of the main
program. Knowing me, I might move the spreadsheet and/or the external
file(s), and break the whole darned thing! LOL

Might be worth a look:
https://blog.capterra.com/free-database-software/
https://www.capterra.com/database-management-software/
https://download.cnet.com/business-databases/windows/3/

--
mick

Ken Springer

2018-06-05 18:39:03 UTC

Post by mick

I'm no database expert either, but I do know not every database need requires
Access or other relational databases.
And finding info about non relational databases seems to be like searching
for hen's teeth.
As I mentioned earlier, I have used Database Oasis in the past, and it was
easy to use. But as I noted... The price has sure gone up.
I had completely forgot about forms in a spreadsheet. That might help a lot,
don't know at this point. I'll have to check the forms capabilities of the
spreadsheet I use, see what it can do. But, I'm not terribly fond of the
idea of an outside link to a file, when the file isn't part of the main
program. Knowing me, I might move the spreadsheet and/or the external
file(s), and break the whole darned thing! LOL

https://blog.capterra.com/free-database-software/
https://www.capterra.com/database-management-software/
https://download.cnet.com/business-databases/windows/3/

Open in tabs in the browser for checking out later.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Ken Springer

2018-06-08 15:43:30 UTC

Post by mick
https://blog.capterra.com/free-database-software/

These are more than I need, but I've added the page to my list of "where
to find" info.

Post by mick
https://www.capterra.com/database-management-software/

Lots of databases listed, but many are enterprise related, mobile and
cloud based.

One that looks interesting is Speedbase, and it's inexpensive.

Post by mick
https://download.cnet.com/business-databases/windows/3/

Everything on this page is horribly outdated. Newest OS listed is Vista.

Just two databases, Filemaker Pro 10 (or 11, depending on the page
you're looking at), and Simple Database.

Filemaker Pro is now owned by Apple, it's version 17, costs $550.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

mick

2018-06-08 19:30:39 UTC

Post by mick
https://blog.capterra.com/free-database-software/

These are more than I need, but I've added the page to my list of "where to
find" info.

Post by mick
https://www.capterra.com/database-management-software/

Lots of databases listed, but many are enterprise related, mobile and cloud
based.
One that looks interesting is Speedbase, and it's inexpensive.

Post by mick
https://download.cnet.com/business-databases/windows/3/

Everything on this page is horribly outdated. Newest OS listed is Vista.
Just two databases, Filemaker Pro 10 (or 11, depending on the page you're
looking at), and Simple Database.
Filemaker Pro is now owned by Apple, it's version 17, costs $550.

Not knowing the type of data and how you were going to use it I
initially thought that maybe you could adapt one of the many
pre-written software packages to your needs, hence the lists.

Speedbase looks like a good choice, never heard of it before but having
had a look at their website I see that it not only uses ready made
templates but it is also customisable so you can start from scratch and
make your own personal databases.

Filemaker Pro is mainly aimed for business use, you can use it at home
for individual use but I think it would be overkill for many people and
a price tag that probably makes it a non-starter. You would be better
off subscribing to Office 365 for 7 to 8 years to get Access and all
the other bits that go with it for the price of Filemaker.
I'm not overly keen on the subscription method for software, still
using Office 2010 Pro here, but I must admit Office 365 does look
attractively priced even for home use, especially when you have more
then one computer.

--
mick

Ken Springer

2018-06-09 13:15:12 UTC

Post by mick

Post by mick
https://blog.capterra.com/free-database-software/

These are more than I need, but I've added the page to my list of "where to
find" info.

Post by mick
https://www.capterra.com/database-management-software/

Lots of databases listed, but many are enterprise related, mobile and cloud
based.
One that looks interesting is Speedbase, and it's inexpensive.

Post by mick
https://download.cnet.com/business-databases/windows/3/

Everything on this page is horribly outdated. Newest OS listed is Vista.
Just two databases, Filemaker Pro 10 (or 11, depending on the page you're
looking at), and Simple Database.
Filemaker Pro is now owned by Apple, it's version 17, costs $550.

Not knowing the type of data and how you were going to use it I
initially thought that maybe you could adapt one of the many
pre-written software packages to your needs, hence the lists.

I know, but even I don't know where the database "needs" will end up. I
have to plan for it to eventually go further than what I can do with a
spreadsheet. Not there yet, and I broke my crystal ball! LOL

I've actually added a couple of fields to it since making the original
post. This could expand past what I'm initially starting.

Post by mick
Speedbase looks like a good choice, never heard of it before but having
had a look at their website I see that it not only uses ready made
templates but it is also customisable so you can start from scratch and
make your own personal databases.

And I don't think the price is bad, either.

Post by mick
Filemaker Pro is mainly aimed for business use, you can use it at home
for individual use but I think it would be overkill for many people and
a price tag that probably makes it a non-starter.

Way back when, Filemaker was a DOS database, easy to use according to my
brother-in-law. I think he's still got a couple of his old databases
and the software.

Caveat... My memory could be faulty, here.

I don't know why Apple purchased it, or when. Maybe they wanted an
Access competitor. But, it would be nice to play with it just for fun.

Post by mick
You would be better
off subscribing to Office 365 for 7 to 8 years to get Access and all
the other bits that go with it for the price of Filemaker.
I'm not overly keen on the subscription method for software, still
using Office 2010 Pro here, but I must admit Office 365 does look
attractively priced even for home use, especially when you have more
then one computer.

Not a chance for anything subscription or cloud based uses here, I don't
recommend that idea for most homeowners. There are definitely business
reasons for it, but maybe a VPN is a better idea.

One question I always ask people, do you really need Office? Or, did
you buy it because someone else said you needed to? Would you buy a
particular new car just because someone else told you that's what you need?

I use Softmaker Pro 2016, not office. So far, does everything I need
and at this time, I want to do. Just checked on the MS website. Office
Home and Student is $150. My cost for Softmaker? If memory is
correct, paid $60. Leaving me $90 to spend elsewhere, maybe a steak
dinner. <G>

Attractively priced? Well, that depends on the individual. Lost in all
of this, the way things are going, companies are starting to price
computers out of the hands of many people.

Rather like the phrase "affordable housing". In Aspen, Co, "affordable
housing" is over $200k. Really? What planet do these people live on?
Which is why no "locals" live in Aspen anymore.

I don't believe in putting my data into the hands of someone else. If
your info isn't out there, as much as possible, it can't get stolen.
So, I have no sympathy for those whose data was taken by Cambridge
Analytica from Facebook.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

J. P. Gilliver (John)

2018-06-05 18:13:30 UTC

In message <pf4o0q$o80$***@news.albasani.net>, Ken Springer
<***@greeleynet.com> writes:
[]

Post by Ken Springer
I'm no database expert either, but I do know not every database need
requires Access or other relational databases.
And finding info about non relational databases seems to be like
searching for hen's teeth.

[]
I'm trying to understand what "relational" actually _means_ here. Rather
than just asking, I did try to look at the wikipedia entry, but it made
my brain hurt ...

I _think_ it means data that's crosslinked in various ways. (I do
genealogy, and I think the software I use is a relational database.) But
this makes me wonder what a _non_-relational database would _be_, other
than some sort of list or table.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

Never make the same mistake twice...there are so many new ones to make!

Ken Springer

2018-06-05 19:08:29 UTC

[]
I'm trying to understand what "relational" actually _means_ here. Rather
than just asking, I did try to look at the wikipedia entry, but it made
my brain hurt ...
I _think_ it means data that's crosslinked in various ways. (I do
genealogy, and I think the software I use is a relational database.) But
this makes me wonder what a _non_-relational database would _be_, other
than some sort of list or table.

Basically, you're right.

Let's say you want to create a music database. You have a choice of
non-relational and relational.

You want the following information in the database:

First Name
Last Name
Album Name
Song Title
Track Number.

A non-relational database is essentially a spreadsheet with more bells
and whistles, and the data displayed is *only* the data you want to see.
In a spreadsheet you see *all* the data at one time. It's held in RAM
(or it used to be) and with enough data, your computer crashes. (This
was the issue when I created the Access 97 database years ago.)

When you enter the data in a non-relational data base, with each new
record for each new song, you have to enter the data listed above for
each and every song. Repeating the same data entry over and over and
over, eating up hard drive space. If you are using a spreadsheet, you
would be eating up your RAM also.

With a relational database, and the information listed above, I would
create 3 separate databases, Artist that would hold First Name and Last
Name. Album for the Album Name. Song for the Song Title and Track Number.

If you have a CD by John Doe, called My Music, and the CD has 12
tracks... Using a form, you would input John and Doe if the appropriate
fields just one time. You would input Album Name just one time. Then,
all you have to enter is the 12 different Song Titles and Track Numbers
until you are finished. Next album is by Mary Smith, and you repeat
these steps.

Essentially, you are removing the need to repeatedly enter the same data.

This means less work for you, since you didn't type John 12 times, Doe
12 times, and the Album Name 12 times. Less space used on the hard drive.

Since a database only displays the data you are working with, and using
less disk space, is why dBase could claim they could store millions of
records using a 640k DOS system and a small hard drive.

In a business scenario, I don't think there would be many situations
where a non-relational database is practical overall. But, for a home
user, it would be, especially if you take into account the learning
curve for a relational database.

With Mick's mentioning of forms in a spreadsheet, I'm going to give that
a try first, now. But there is one field of info that could be my
downfall. I won't know until I start inputting the data as I get it.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

J. P. Gilliver (John)

2018-06-05 19:36:30 UTC

[]
I'm trying to understand what "relational" actually _means_ here. Rather
than just asking, I did try to look at the wikipedia entry, but it made
my brain hurt ...
I _think_ it means data that's crosslinked in various ways. (I do
genealogy, and I think the software I use is a relational database.) But
this makes me wonder what a _non_-relational database would _be_, other
than some sort of list or table.

Basically, you're right.
Let's say you want to create a music database. You have a choice of
non-relational and relational.
First Name
Last Name
Album Name
Song Title
Track Number.
A non-relational database is essentially a spreadsheet with more bells
and whistles, and the data displayed is *only* the data you want to
see. In a spreadsheet you see *all* the data at one time. It's held
in RAM (or it used to be) and with enough data, your computer crashes.
(This was the issue when I created the Access 97 database years ago.)
When you enter the data in a non-relational data base, with each new
record for each new song, you have to enter the data listed above for
each and every song. Repeating the same data entry over and over and
over, eating up hard drive space. If you are using a spreadsheet, you
would be eating up your RAM also.
With a relational database, and the information listed above, I would
create 3 separate databases, Artist that would hold First Name and Last
Name. Album for the Album Name. Song for the Song Title and Track Number.
If you have a CD by John Doe, called My Music, and the CD has 12
tracks... Using a form, you would input John and Doe if the
appropriate fields just one time. You would input Album Name just one
time. Then, all you have to enter is the 12 different Song Titles and
Track Numbers until you are finished. Next album is by Mary Smith, and
you repeat these steps.
Essentially, you are removing the need to repeatedly enter the same data.

Automatic ditto marks, in other words. But I think a relational database
involves more than just saving time entering data. (That could be
achieved with just a form for data entry, with an "OK" or "Enter"
button, where clicking that button to say you've finished entering a
record _doesn't_ clear all the fields for the next record.) I think Wolf
K. has it more, using my genealogy example: records are linked in
assorted ways - entering Fred as the son of John Doe also enters John as
Fred's father, and Fred as Jane's son too.

Post by Ken Springer
This means less work for you, since you didn't type John 12 times, Doe
12 times, and the Album Name 12 times. Less space used on the hard drive.
Since a database only displays the data you are working with, and using
less disk space, is why dBase could claim they could store millions of
records using a 640k DOS system and a small hard drive.

I think there's more to it than just using less space.

Post by Ken Springer
In a business scenario, I don't think there would be many situations
where a non-relational database is practical overall. But, for a home
user, it would be, especially if you take into account the learning
curve for a relational database.

I'm still not sure what a _non_-relational database would be, other than
a plain table (by which I mean a grid), or CSV list.

Post by Ken Springer
With Mick's mentioning of forms in a spreadsheet, I'm going to give
that a try first, now. But there is one field of info that could be my
downfall. I won't know until I start inputting the data as I get it.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

A dishwasher is rubbish at making treacle sponge. - Marjorie in UMRA, 2017-1-15

Ken Springer

2018-06-05 22:16:01 UTC

[]
I'm trying to understand what "relational" actually _means_ here. Rather
than just asking, I did try to look at the wikipedia entry, but it made
my brain hurt ...
I _think_ it means data that's crosslinked in various ways. (I do
genealogy, and I think the software I use is a relational database.) But
this makes me wonder what a _non_-relational database would _be_, other
than some sort of list or table.

Wolf is 100% correct, I was just trying to keep it as simple as possible
in order to grasp the basic different.

I think there's more to it than just using less space.

You have to consider this combined with the above.

I'm still not sure what a _non_-relational database would be, other than
a plain table (by which I mean a grid), or CSV list.

The actual database is just that. But it's the bells and whistles of
what you can do to manipulate the data that gives you more options of
how to view the data.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-05 19:54:25 UTC

"Ken Springer" <***@greeleynet.com> wrote

| You want the following information in the database:
|
| First Name
| Last Name
| Album Name
| Song Title
| Track Number.
|
| A non-relational database is essentially a spreadsheet with more bells
| and whistles, and the data displayed is *only* the data you want to see.
| In a spreadsheet you see *all* the data at one time. It's held in RAM
| (or it used to be) and with enough data, your computer crashes. (This
| was the issue when I created the Access 97 database years ago.)
|
| When you enter the data in a non-relational data base, with each new
| record for each new song, you have to enter the data listed above for
| each and every song. Repeating the same data entry over and over and
| over, eating up hard drive space. If you are using a spreadsheet, you
| would be eating up your RAM also.
|
| With a relational database, and the information listed above, I would
| create 3 separate databases, Artist that would hold First Name and Last
| Name. Album for the Album Name. Song for the Song Title and Track
Number.
|
| If you have a CD by John Doe, called My Music, and the CD has 12
| tracks... Using a form, you would input John and Doe if the appropriate
| fields just one time. You would input Album Name just one time. Then,
| all you have to enter is the 12 different Song Titles and Track Numbers
| until you are finished. Next album is by Mary Smith, and you repeat
| these steps.
|

That doesn't seem to make sense. The data then doesn't
relate. I would do the same thing as one table. Then I
can search for Song.singer where Song.name = "abc"
and Song.album = "My Music", and get "John Doe". If you
have 3 tables then they don't connect. You can't search
for Song.Name where Album.Name = "My Music". The Album
table is then just a list of albums. If they're not going to
connect then there's no reason to have extra tables.
You could just as well have one table with one field that's
all the info about a song.

You could do something like search for Song.Singer
where Song.Name = Album.SongName and Album.Name
= "My Music", but you need redundant fields in different
tables for that. I don't think it's about saving space
but rather about accessing data flexibly and quickly.

I don't see why you'd use a spreadsheet either way. It's
not handy either to view or edit beyond a very limited
size. Won't you always want a "Form" or front-end
customized to the specific database?

I tried SSuite out of curiosity. It seems very simple
and straightforward to make a DB, add tables and
fields, then fill those in. But there's not much sense
trying to use it in that format. Ideally someone would
create a custom interface that allows you to add
more rows easily, like a webpage form, and search
for entries at a click.

Ken Springer

2018-06-05 22:46:35 UTC

Post by Mayayana
|
| First Name
| Last Name
| Album Name
| Song Title
| Track Number.
|
| A non-relational database is essentially a spreadsheet with more bells
| and whistles, and the data displayed is *only* the data you want to see.
| In a spreadsheet you see *all* the data at one time. It's held in RAM
| (or it used to be) and with enough data, your computer crashes. (This
| was the issue when I created the Access 97 database years ago.)
|
| When you enter the data in a non-relational data base, with each new
| record for each new song, you have to enter the data listed above for
| each and every song. Repeating the same data entry over and over and
| over, eating up hard drive space. If you are using a spreadsheet, you
| would be eating up your RAM also.
|
| With a relational database, and the information listed above, I would
| create 3 separate databases, Artist that would hold First Name and Last
| Name. Album for the Album Name. Song for the Song Title and Track
Number.
|
| If you have a CD by John Doe, called My Music, and the CD has 12
| tracks... Using a form, you would input John and Doe if the appropriate
| fields just one time. You would input Album Name just one time. Then,
| all you have to enter is the 12 different Song Titles and Track Numbers
| until you are finished. Next album is by Mary Smith, and you repeat
| these steps.
|
That doesn't seem to make sense. The data then doesn't
relate. I would do the same thing as one table.

If you do it all in one table, it's non-relational.

Post by Mayayana
Then I
can search for Song.singer where Song.name = "abc"
and Song.album = "My Music", and get "John Doe". If you
have 3 tables then they don't connect. You can't search
for Song.Name where Album.Name = "My Music".

This is where "queries" comes in, you can create a search that covers
all 3 tables to get the answer you're looking for.

Post by Mayayana
The Album
table is then just a list of albums. If they're not going to
connect then there's no reason to have extra tables.
You could just as well have one table with one field that's
all the info about a song.

But, you don't leave those tables disconnected. You "relate"/connect
the tables with links between tables. This screenshot will show you the
links between various tables in a database.

Loading Image...

Access does exactly the same thing.

Let's say you have 10 albums by John Doe, and each album has 10 tracks.

If you have everything in one table, you have to enter the name 100
times. (Remember, this is being built from scratch, no previous data
entry anywhere.) You enter each album name 10 times. And each track once.

If it's a relational database, you enter the name once, not 100 times.
You enter each album name once, not 10 times. That saves you time, as
well as disk space.

To us, the disk space is likely unimportant, given we now have terabyte
sized drives. But when dBase came out, we had 10 and 20 megabyte
drives. Space saving methods were important, as was good programming
because of limited RAM.

Think about this... You're Amazon. Do you want to pay for the extra
hardware to have the name and address of 100,000,000 customers entered
and stored on your hard drives 500 times, once for each order placed by
those customers? Or, would you rather have the name and address of each
customer entered just once? <BG>

Post by Mayayana
You could do something like search for Song.Singer
where Song.Name = Album.SongName and Album.Name
= "My Music", but you need redundant fields in different
tables for that. I don't think it's about saving space
but rather about accessing data flexibly and quickly.

To link one table to another, you just need one common field in each
table. And you can create a field specifically for that purpose.

With really large databases, such as what Amazon has, it's both saving
space as well as accessing data.

Post by Mayayana
I don't see why you'd use a spreadsheet either way. It's
not handy either to view or edit beyond a very limited
size. Won't you always want a "Form" or front-end
customized to the specific database?

It's a matter of scale. For my current need, I'd be surprised if I end
up with 100 records. With using a form, the spreadsheet may be all that
I need, since I'd forgotten about forms.

Post by Mayayana
I tried SSuite out of curiosity. It seems very simple
and straightforward to make a DB, add tables and
fields, then fill those in. But there's not much sense
trying to use it in that format. Ideally someone would
create a custom interface that allows you to add
more rows easily, like a webpage form, and search
for entries at a click.

All of the suite, or just Monobase?

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-06 00:33:12 UTC

"Ken Springer" <***@greeleynet.com> wrote

| If you do it all in one table, it's non-relational.

Maybe I've got it wrong, but I don't see it that way.
With one table I can run a query like:

Select Song.Singer WHERE Song.Name is "xyz"
AND Song.Album is "My Music"

It allows me to return specific records based on
relationships between data elements. It allows me
to return any specific data or patterns that I want
to. I don't see how you can do that better using
multiple tables.

| This is where "queries" comes in, you can create a search that covers
| all 3 tables to get the answer you're looking for.
|

But my query above achieves that with only
one table.

I get the idea of tables being connected but
can you give an actual example? I've never been
trained in this or done it professionally and I
just don't see why tables need to be so complex.
The PNG sample you linked seems to be a different
case, with a large amount of data needed for
each entry. But that seems to me more
expensive rather than less. Something to be
avoided where possible. In other words, something
to be used only when the complexity of data
warrants it.

For instance, if enough fields are needed to
justify multiple tables then that makes sense, but
in a case where you only need, say, 7 fields to
store all relevant customer data, it would be
excessive complication to store it in multiple
tables. (The sample in the PNG is actually unlikely.
The separate Address table makes sense at first
glance. But for a typical address entry one would
only need street and city, not 2 streets, district,
and city. With only 2 address fields it can go in
the customer table, thus also doing away
with the unique key field in the Address table.
Since address is part of the basic customer data
there's really no reason to store it in another table.)

If John Doe only has one entry in the Album
table I can see that being efficient, but I don't
see how it's going to be efficient in practice,
over just having 5 fields for each song in a single
table. You'll need extra fields to connect the
tables, so I don't see where the idea of saving
space comes in. How, specifically, are you going
to set up the tables for songs in a way that's
better than setting them up as a single table,
given that you only have 5 data elements for each
song in the first place?
What are the fields in Song, Album and Singer
tables, and what is the query to find out who
sings "xyz" on an album named "My Music"? And
how would that be superior to a single table?

There are also wide differences in what data
one needs to store. For instance, I created a database
with one table of 55,000 records to provide ZIP
codes and area codes in the US. Each entry has
a key field, ZIP code, city, state, and area code.
I can do a query to match up cities, ZIP codes
and area codes in either direction. I can also return
multiples, such as all ZIP codes used in NYC. And
it works instantly. How could that be improved by
having more than one table?

|
| All of the suite, or just Monobase?
|

Just Monobase. The whole thing looks interesting.
I'd never heard of it before. But I use Libre Office and
am not in the market for a replacement.

Ken Springer

2018-06-06 02:37:58 UTC

Post by Mayayana
| If you do it all in one table, it's non-relational.
Maybe I've got it wrong, but I don't see it that way.
Select Song.Singer WHERE Song.Name is "xyz"
AND Song.Album is "My Music"
It allows me to return specific records based on
relationships between data elements. It allows me
to return any specific data or patterns that I want
to. I don't see how you can do that better using
multiple tables.

But, I'm not talking about doing queries, you are. <BG> I'm talking
about having to enter the same data over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over and over and over and
over and over and over and over and over and over. LOL (Sorry,
couldn't resist that! LOL)

Post by Mayayana
| This is where "queries" comes in, you can create a search that covers
| all 3 tables to get the answer you're looking for.
|
But my query above achieves that with only
one table.

And, it works, when the database is simple and small. But relational
databases with their related queries are for databases that are massive
in size, and complex in need.

That's why I don't want one. <G>

Post by Mayayana
I get the idea of tables being connected but
can you give an actual example?

I've never needed to do anything as complex as in the screenshot I
linked. I think I've done only two relational databases, one for my
employer in the early '90's (?), the other a music collection for my
inlaws in 2001 or 2002.

By the time I finished the music collection, there were around 35,000
records. Fortunately, I had multiple spreadsheets of info I could
import. But when it was finished, they had to add more CD's, one
track/record at a time. I have no clue how many more records have been
added, but I'm sure they like having to add the artist just once for
each album. Fact is, they probably don't have to add any new artists,
they probably already have the artist in the database.

Post by Mayayana
I've never been
trained in this or done it professionally and I
just don't see why tables need to be so complex.
The PNG sample you linked seems to be a different
case, with a large amount of data needed for
each entry.

I have no idea why that database in the PNG is that complex. A question
for the author(s).

Post by Mayayana
But that seems to me more
expensive rather than less. Something to be
avoided where possible. In other words, something
to be used only when the complexity of data
warrants it.

The crossover point of expense does depend on the amount and type of
data that needs to be processed. As I said, I don't need a relational
database for my project.

Post by Mayayana
For instance, if enough fields are needed to
justify multiple tables then that makes sense, but
in a case where you only need, say, 7 fields to
store all relevant customer data, it would be
excessive complication to store it in multiple
tables.

Exactly. Which is why I started looking for a non-relational database. :-)

Post by Mayayana
(The sample in the PNG is actually unlikely.
The separate Address table makes sense at first
glance. But for a typical address entry one would
only need street and city, not 2 streets, district,
and city. With only 2 address fields it can go in
the customer table, thus also doing away
with the unique key field in the Address table.
Since address is part of the basic customer data
there's really no reason to store it in another table.)

But, look at the Customer Data. It includes country, so they obviously
have to deal with foreign addresses. Don't some of their addresses have
two streets? I know some US addresses need two street street fields.

Based on the Views section we can see, I'm thinking it's some sort of
database for a chain of video stores, such as Blockbuster or Hollywood,
and who knows where those stores are.

Post by Mayayana
If John Doe only has one entry in the Album
table I can see that being efficient, but I don't
see how it's going to be efficient in practice,
over just having 5 fields for each song in a single
table. You'll need extra fields to connect the
tables, so I don't see where the idea of saving
space comes in. How, specifically, are you going
to set up the tables for songs in a way that's
better than setting them up as a single table,
given that you only have 5 data elements for each
song in the first place?

If you only have one, yes. But what if you have to type John Doe, into
two fields, 500 times? How much time is it going to take you to do that?

Keeping it simple, let's say the two fields, one for John, one for Doe.
But, not every name is that short. What if the artist's name is
Frederick Flintstone? You have to make the field long enough to hold
any conceivable name. What about middle names. What if the artist name
is John Jacob Jingleheimer Schmidt? I don't know if there's anyone with
that name, but it is the name of a song. <G>

Let's say you make the first name field 25 bytes, and the last name
field is 50 bytes. Last names do tend to be longer. Plus however many
bytes are needed for the program to keep track of everything, which I'll
ignore.

We now have 75 bytes reserved for first and last name for each record.
The database I made for my inlaws had around 35k of records. Each
record has 75 bytes for the name. 35k X 75 = 2,625,000 bytes reserved
on the HD for just first and last name.

If you knew my inlaws, you'd know it's not inconceivable (the favorite
word of Vizzini in The Princess Bride) to have 10 albums by John Doe.
Albums seem to average 15 tracks. If you use a non-relational database,
for those 10 albums of 15 tracks, you'll have 75 bytes X 10 albums X 15
tracks for a total of 11,250 bytes used when you could have just 75
bytes used. And when the information is put in track by track, that's a
lot of typing you have to do.

Want to volunteer to do that much typing? :-)

Depending on what you are doing, it may not be necessary to create a
special field for the link. You just have to have the same field in
both tables.

Post by Mayayana
What are the fields in Song, Album and Singer
tables, and what is the query to find out who
sings "xyz" on an album named "My Music"? And
how would that be superior to a single table?

I have no idea what I did 16+ years ago. I'd probably start with 50 for
the song, and 50 for the artist. There are some long names out there,
and I don't know the longest. Look at John Jacob Jingleheimer Schmidt
for a song title, and Nitty Gritty Dirt Band for the artist, or Eddy
Arnold and the Arizona Plowboys for the artist.

Post by Mayayana
There are also wide differences in what data
one needs to store. For instance, I created a database
with one table of 55,000 records to provide ZIP
codes and area codes in the US. Each entry has
a key field, ZIP code, city, state, and area code.
I can do a query to match up cities, ZIP codes
and area codes in either direction. I can also return
multiples, such as all ZIP codes used in NYC. And
it works instantly. How could that be improved by
having more than one table?

If that's all the information you need, you don't need multiple tables.
And it's not a lot of work if the information has already been typed in
by someone. Did you type in each of those 55,000 records?

But your database isn't tied to keeping track of shipping, shipping
costs, labor, transportation, inventory, etc. This is the type of
project where you need a relational database.

But... How many times do I have to say it... I don't need a relational
database. So why are we discussing using a relational database for my
small project? <G>

Post by Mayayana
|
| All of the suite, or just Monobase?
|
Just Monobase. The whole thing looks interesting.
I'd never heard of it before. But I use Libre Office and
am not in the market for a replacement.

I tried the word processor years ago, very different user interface at
that time.

I used to use Libre Office years ago, but left when they told me the
bugs I reported were not important. The attitude pissed me off. I
began to wonder why I wanted to deal with that attitude, trying to use
broken features that were important to me. So I went elsewhere.

Eventually, I realized not everyone needs an office suite with thousand
of features, so why was I looking at suites of MS Office calibre? So,
just like I did in my 8 bit days, I tried a lot of programs, to find one
that I liked to use, and wasn't overblown for my needs.

I've settled on Softmaker Office 2016, which cost me about 2/3 what
Office Home and Student/Business would have cost me, and doesn't include
things I don't need. :-)

OH!! BTW, did you notice the screenshot is from a Mac? LOL

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-06 03:41:23 UTC

"Ken Springer" <***@greeleynet.com> wrote

| I have no idea why that database in the PNG is that complex. A question
| for the author(s).
|

I wonder if it's connected to the temperament of
people who make databases. There's a peculiar
beancounter neurosis that makes people want to
organize facts far beyond any purpose of rationality.
A vehement compulsion for order. It's the kind of
person I fear will bring about 1984. Recording
and analyzing everything simply because we can.
Like scientists creating new kinds of bombs, they
only see the technical details and not the big
picture.

The MSI design that Microsoft came up with is
similar. It's stunningly complex and overproduced.
Yet I don't doubt that every table and field has
some kind of "logical" reason for existing. Somewhere
there's a maniac luxuriating in the "perfection" of
those 80+ tables they created to do what used to
be accomplished with a simple INI file.

| If that's all the information you need, you don't need multiple tables.
| And it's not a lot of work if the information has already been typed in
| by someone. Did you type in each of those 55,000 records?
|

I think I downloaded the list from somewhere and then
wrote scripts to format it such that I could import it as
a finished table into an MSI. I can't imagine a situation
where I'd actually be entering each record. I once made
a very basic text file database to catalog about 800
software customers. But even with that I never entered
anything by hand. I'd get an order email with a particular
format and the database front-end would process that,
automating the creation of a new record. I only needed
to click a button here or there to enter a new record,
once I got it set up.

But it does sound like your music catalog had to be
built up by hand, since you didn't start with digital
records of the CDs.

So I guess there are a lot of different database
designs and uses.

| But... How many times do I have to say it... I don't need a relational
| database. So why are we discussing using a relational database for my
| small project? <G>
|

I'm still not entirely clear what makes it relational.
I thought it was essentially in being SQL-based and
thus allowing for customized queries that deal in
relationships between data fields.

Anyway, thank you for your time with this. I'm
somewhat playing devil's advocate, but only because
I'm curious about how people use databases in
ways that I may not understand or ways I may
not have thought of.

| I used to use Libre Office years ago, but left when they told me the
| bugs I reported were not important. The attitude pissed me off.

OSS. It operates with a paramilitary-style pecking
order hierarchy. Funny thing. There's a joke that
managing programmers is like herding cats. Yet so
many of them seem to be unable to stand alone.
They want to be part of a tightly structured "team"
and they want to know their place. You need to join
and learn the rules before you can even report a bug
in a way they can recognize.

| Eventually, I realized not everyone needs an office suite with thousand
| of features, so why was I looking at suites of MS Office calibre?

I use LO. I've never really learned the details
of using a word processor. They drive me crazy.
But once in awhile I have to have something
and LO can handle it: Contracts, receipts,
estimates, address labels.... I don't use it to
write letters. Only to create a few template
files that I then can use over and over.

Apd

2018-06-06 12:29:25 UTC

Post by Mayayana
I'm still not entirely clear what makes it relational.

The fact that it has multiple tables that can be related to each
other.

Post by Mayayana
I thought it was essentially in being SQL-based and
thus allowing for customized queries that deal in
relationships between data fields.

The relationship is between tables that share a common unique field.

Suppose you are a business that sells products and/or services. You
will have a table of customers with contact details (perhaps because
they need to be invoiced regularly) and you will have a table for an
inventory of goods or types of service you offer. You then want to
keep details of who has bought what so you'll have another table that
links these two together.

So the fields in the tables might look something like this:

--Customer--
Account Number:
Name:
Address:

--Product--
Product Code:
Description:
Price:

--Sales--
Invoice Number:
Date:
Account Number:
Product Code:
Quantity:

You can see that the sales table uses the customer account no. and
product code to link to records from those tables so it doesn't have
to needlessly duplicate this info.

Mayayana

2018-06-06 12:58:22 UTC

"Apd" <***@all.invalid> wrote

| So the fields in the tables might look something like this:
|
| --Customer--
| Account Number:
| Name:
| Address:
|
| --Product--
| Product Code:
| Description:
| Price:
|
| --Sales--
| Invoice Number:
| Date:
| Account Number:
| Product Code:
| Quantity:
|
| You can see that the sales table uses the customer account no. and
| product code to link to records from those tables so it doesn't have
| to needlessly duplicate this info.
|
Yes. That's a good example. Thanks. Though
Wikipedia says the relation is in the matching
row structure and not in the number of tables.

https://en.wikipedia.org/wiki/Relational_database

If you put all the data in one table it would
still be as useful. You could still quickly find
what Ed Smith bought this month. And if
some poor soul has to actually type in that
data they won't be saved any work if the
backend has 3 tables instead of 1. There's
only a slight improvement in storage space
needed for the database.

Apd

2018-06-06 14:26:50 UTC

Indeed. "Rows in a table can be linked to rows in other tables by
adding a column for the unique key of the linked row". In my example:
"Account Number" and "Product Code".

Post by Mayayana
If you put all the data in one table it would
still be as useful. You could still quickly find
what Ed Smith bought this month.

All true.

Post by Mayayana
And if
some poor soul has to actually type in that
data they won't be saved any work if the
backend has 3 tables instead of 1.

So which table will you keep? If you only have the sales table,
where's the list of products so you can find the price? If you have
to invoice Joe Bloggs every month for a service where do you keep his
contact details? Surely you don't look at the last invoice and copy
them over?

Post by Mayayana
There's
only a slight improvement in storage space
needed for the database.

It's more to do with organisation of your data. Widgets have no
relationship to people until somebody buys one. It also does save time
and the likelihood of mistakes in data entry. You only want to be
entering Joe's details once and you only want to enter a description
of the super special widget x (in blue!) once because many people may
buy them.

Ken Springer

2018-06-06 15:17:31 UTC

Post by Mayayana
|
| --Customer--
|
| --Product--
|
| --Sales--
|
| You can see that the sales table uses the customer account no. and
| product code to link to records from those tables so it doesn't have
| to needlessly duplicate this info.
|
Yes. That's a good example. Thanks. Though
Wikipedia says the relation is in the matching
row structure and not in the number of tables.
https://en.wikipedia.org/wiki/Relational_database
If you put all the data in one table it would
still be as useful. You could still quickly find
what Ed Smith bought this month. And if
some poor soul has to actually type in that
data they won't be saved any work if the
backend has 3 tables instead of 1. There's
only a slight improvement in storage space
needed for the database.

But, you would have to enter Ed Smith's information for each item Ed
bought. That's because each item Ed bought would be a separate record.
So if Ed buys 100 items, you enter Ed's info 100 times. :-)

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Ken Springer

2018-06-06 15:15:12 UTC

Post by Mayayana
| I have no idea why that database in the PNG is that complex. A question
| for the author(s).
|
I wonder if it's connected to the temperament of
people who make databases. There's a peculiar
beancounter neurosis that makes people want to
organize facts far beyond any purpose of rationality.
A vehement compulsion for order.

The more detailed and "broken down" your data is, the more ways you can
organize and view the data to learn something you need to know.

When I was doing just a few databases on my 8-bit computer, for
different reasons, I learned early on to break the data into as small of
pieces as you can. How did I learn this? Because I had to continually
go back and redo the database so I could extract the information I was
looking for.

Post by Mayayana
It's the kind of
person I fear will bring about 1984. Recording
and analyzing everything simply because we can.
Like scientists creating new kinds of bombs, they
only see the technical details and not the big
picture.

You are right. Which is why we, as citizens, and our elected officials
need to understand how computer and systems operate, so proper oversight
and controls can be implemented.

Post by Mayayana
The MSI design that Microsoft came up with is
similar. It's stunningly complex and overproduced.
Yet I don't doubt that every table and field has
some kind of "logical" reason for existing. Somewhere
there's a maniac luxuriating in the "perfection" of
those 80+ tables they created to do what used to
be accomplished with a simple INI file.

At the MS end, they have the problem of giving the programmers all the
tools needed. Fred may need one thing, but John needs another. So MS
has to provide 2 tools, not 1. And on and on.

Post by Mayayana
| If that's all the information you need, you don't need multiple tables.
| And it's not a lot of work if the information has already been typed in
| by someone. Did you type in each of those 55,000 records?
|
I think I downloaded the list from somewhere and then
wrote scripts to format it such that I could import it as
a finished table into an MSI. I can't imagine a situation
where I'd actually be entering each record. I once made
a very basic text file database to catalog about 800
software customers. But even with that I never entered
anything by hand. I'd get an order email with a particular
format and the database front-end would process that,
automating the creation of a new record. I only needed
to click a button here or there to enter a new record,
once I got it set up.

Reality? It doesn't matter where or how you got the data. Somebody,
somewhere, manually entered the data. X number of people manually
entered those 55,000 records. <G>

Post by Mayayana
But it does sound like your music catalog had to be
built up by hand, since you didn't start with digital
records of the CDs.

Yep. And my brother-in-law has dBase files of information from his
reel-to-reel and cassette tapes, too.

Post by Mayayana
So I guess there are a lot of different database
designs and uses.

Tons! LOL An accounting program is a database. Inventory software is
a database. A point-of-sale system is a database. If you do something
that needs to store and retain data, it's a database at some level.

Post by Mayayana
| But... How many times do I have to say it... I don't need a relational
| database. So why are we discussing using a relational database for my
| small project? <G>
|
I'm still not entirely clear what makes it relational.
I thought it was essentially in being SQL-based and
thus allowing for customized queries that deal in
relationships between data fields.

To build on Apd's explanation, when you request information via a query,
and it pulls the answers from multiple tables, it's relational.

Post by Mayayana
Anyway, thank you for your time with this. I'm
somewhat playing devil's advocate, but only because
I'm curious about how people use databases in
ways that I may not understand or ways I may
not have thought of.

You're welcome, and I don't mind the devil's advocate idea at all. 'Tis
a good thing.

I used to go round and round with an engineer in the same way. We each
took something away from the discussion. What I told him, one time, was
I thought we always came out with a better project in the end.

Post by Mayayana
| I used to use Libre Office years ago, but left when they told me the
| bugs I reported were not important. The attitude pissed me off.
OSS. It operates with a paramilitary-style pecking
order hierarchy. Funny thing. There's a joke that
managing programmers is like herding cats. Yet so
many of them seem to be unable to stand alone.
They want to be part of a tightly structured "team"
and they want to know their place. You need to join
and learn the rules before you can even report a bug
in a way they can recognize.

Agreed. And many of them seem to have a "my way or the highway" attitude.

Post by Mayayana
| Eventually, I realized not everyone needs an office suite with thousand
| of features, so why was I looking at suites of MS Office calibre?
I use LO. I've never really learned the details
of using a word processor. They drive me crazy.
But once in awhile I have to have something
and LO can handle it: Contracts, receipts,
estimates, address labels.... I don't use it to
write letters. Only to create a few template
files that I then can use over and over.

I like word processors, and what you can do when you need to create
documents. Especially multiple page docs. When it comes to major
changes, such as different sized subheadings, changing the entire font
for the doc, whatever, if you know how to use the features of a word
processor, editing can be a breeze for those types of changes, or a PITA
if you don't know how.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

J. P. Gilliver (John)

2018-06-06 16:28:53 UTC

[]

You're welcome, and I don't mind the devil's advocate idea at all. 'Tis
a good thing.

+1. As is explaining - even to the explainer; what we used to call
"cardboard cutout" when I was at messybeast, and I think the expression
is more widely known: just explaining something to someone, even if they
don't say anything (as if they were just a cardboard image of
themselves), can help you solve something.

I used to go round and round with an engineer in the same way. We each
took something away from the discussion. What I told him, one time,
was I thought we always came out with a better project in the end.

Indeed.
[]

Certainly, trying to sort out "styles" in Word has often had me climbing
the walls - it's certainly not intuitive. To the extent that if I've
been in a hurry I've just adjusted the formatting of individual bits
myself, probably creating multiple styles I didn't need in the process.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

Have the courage to be ordinary - people make themselves so desperately unhappy
trying to be clever and totally original. (Robbie Coltrane, RT 8-14 Nov. 1997.)

Ken Springer

2018-06-06 20:10:16 UTC

You're welcome, and I don't mind the devil's advocate idea at all. 'Tis
a good thing.

Indeed.
[]

I got into how to deal with styles in the office suite I currently use.
(Definitely not MS Office.) I went to their forums for help, and after
finding out how they worked, it's a piece of cake to create what I want.

My preferred suite also has a 600 page PDF manual for the word processor
you can download for free. So, people's argument that it's too
expensive is hogwash. The vendor simply has to want to do it.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-06 21:31:33 UTC

"Ken Springer" <***@greeleynet.com> wrote

| > | If that's all the information you need, you don't need multiple
tables.
| > | And it's not a lot of work if the information has already been typed
in
| > | by someone. Did you type in each of those 55,000 records?
| > |
| >
| > I think I downloaded the list from somewhere and then
| > wrote scripts to format it such that I could import it as
| > a finished table into an MSI. I can't imagine a situation
| > where I'd actually be entering each record. I once made
| > a very basic text file database to catalog about 800
| > software customers. But even with that I never entered
| > anything by hand. I'd get an order email with a particular
| > format and the database front-end would process that,
| > automating the creation of a new record. I only needed
| > to click a button here or there to enter a new record,
| > once I got it set up.
|
| Reality? It doesn't matter where or how you got the data. Somebody,
| somewhere, manually entered the data. X number of people manually
| entered those 55,000 records. <G>
|

Not in my universe. In other words, for this particular
database, ease of entry is not relevant because I never
did and never will need to enter single ZIP code data.
The notion that someone probably did at some point
is neither here nor there.
Likewise, my GUI for the ZIP code database has no
option to edit or add records, because that's not
relevant.

So there's a big difference to me, comparing a
database with 55,000 records that I created in
a few inutes with a script, vs a database with
100 records that needs a data entry GUI and has
each record entered manually.

| To build on Apd's explanation, when you request information via a query,
| and it pulls the answers from multiple tables, it's relational.
|

See the Wikipedia link. The *multiple* tables
is not relevant to it being relational. Apd showed
an example of a database that really benefits from
multiple tables, but the relationships between data
don't differ between that and a single table. Only
the query details will vary.

Ken Springer

2018-06-06 21:45:56 UTC

Post by Mayayana
| > | If that's all the information you need, you don't need multiple
tables.
| > | And it's not a lot of work if the information has already been typed
in
| > | by someone. Did you type in each of those 55,000 records?
| > |
| >
| > I think I downloaded the list from somewhere and then
| > wrote scripts to format it such that I could import it as
| > a finished table into an MSI. I can't imagine a situation
| > where I'd actually be entering each record. I once made
| > a very basic text file database to catalog about 800
| > software customers. But even with that I never entered
| > anything by hand. I'd get an order email with a particular
| > format and the database front-end would process that,
| > automating the creation of a new record. I only needed
| > to click a button here or there to enter a new record,
| > once I got it set up.
|
| Reality? It doesn't matter where or how you got the data. Somebody,
| somewhere, manually entered the data. X number of people manually
| entered those 55,000 records. <G>
|
Not in my universe. In other words, for this particular
database, ease of entry is not relevant because I never
did and never will need to enter single ZIP code data.
The notion that someone probably did at some point
is neither here nor there.

IOW, you lived off someone else's work. <G>

Post by Mayayana
Likewise, my GUI for the ZIP code database has no
option to edit or add records, because that's not
relevant.
So there's a big difference to me, comparing a
database with 55,000 records that I created in
a few inutes with a script, vs a database with
100 records that needs a data entry GUI and has
each record entered manually.
| To build on Apd's explanation, when you request information via a query,
| and it pulls the answers from multiple tables, it's relational.
|
See the Wikipedia link. The *multiple* tables
is not relevant to it being relational. Apd showed
an example of a database that really benefits from
multiple tables, but the relationships between data
don't differ between that and a single table. Only
the query details will vary.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-06 22:27:41 UTC

"Ken Springer" <***@greeleynet.com> wrote

| > | Reality? It doesn't matter where or how you got the data. Somebody,
| > | somewhere, manually entered the data. X number of people manually
| > | entered those 55,000 records. <G>
| > |
| >
| > Not in my universe. In other words, for this particular
| > database, ease of entry is not relevant because I never
| > did and never will need to enter single ZIP code data.
| > The notion that someone probably did at some point
| > is neither here nor there.
|
| IOW, you lived off someone else's work. <G>
|

Yes. Whenever possible. That's the nice thing about
computers. Once someone enters the data digitally it's
available in general. It's possible I could have gone to the
library and hand-copied all those ZIP codes, while wearing
a hairshirt. But I'm a lush. I just went online and looked
for a list of ZIP codes.
It gets worse. I just drove home on roads today built
by others. I didn't forge a new one. I'm shameless.

On the bright side, the original ZIP code work was
probably not done by exploited, underpaid lackeys but
rather by postal service workers who get paid more
money and get better benefits than either you or I --
salary and benefits that come out of my taxes and
stamp purchases. The postal service is not technically
US gov't, but gov't data is supposed to be free by
law. (Nice to know. It means that you can use NASA
photos roylaty-free, for any purpose you like. Because
we taxpayers paid for them.)

As I described earlier, I don't typically need a
database with data entry/edit functionality. My
email database is editable, but adding the email
is automated by a script(s). My geo-location
database was created using free data provided
by MaxMind.com. My ZIP code database, as noted,
was created quickly, using an existing list as CSV
file.
If I were making a database for someone's music
collection I'd probably also try to automate it. A
day of coding scripts to walk 1,000s of MP3s and
parse their headers/names seems easier to me than
spending 3 weeks doing it by hand.

The only database I've ever needed that I wanted
data entry functionality for is the one I made for a
customer list. That one is so simple, and relatively
small, that it doesn't even have tables. It just uses
10-line software purchase "records" separated by
***, in a plain text file. Basic string searching
methods are adequate for the functionality.

Mayayana

2018-06-06 22:42:31 UTC

"Mayayana" <***@invalid.nospam> wrote

| The only database I've ever needed that I wanted
| data entry functionality for ....

I take that back. I made an MSI-based database
for storing snippets of programming code. It could
be used for storing any kind of text blobs. Recipes,
for instance. I give it away. Some people find it very
useful to use as a code library, but I've never really
used it myself. It doesn't seem worth all the data
organization and data entry that would be required
for it to be truly useful to me. I guess I need a lackey.

Ken Springer

2018-06-07 02:18:25 UTC

Post by Mayayana
| > | Reality? It doesn't matter where or how you got the data. Somebody,
| > | somewhere, manually entered the data. X number of people manually
| > | entered those 55,000 records. <G>
| > |
| >
| > Not in my universe. In other words, for this particular
| > database, ease of entry is not relevant because I never
| > did and never will need to enter single ZIP code data.
| > The notion that someone probably did at some point
| > is neither here nor there.
|
| IOW, you lived off someone else's work. <G>
|
Yes. Whenever possible. That's the nice thing about
computers. Once someone enters the data digitally it's
available in general. It's possible I could have gone to the
library and hand-copied all those ZIP codes, while wearing
a hairshirt. But I'm a lush. I just went online and looked
for a list of ZIP codes.

And I don't blame you a bit. LOL I'd do the same thing, if it was
possible.

But so much day to day database operations are in real time. Sales
invoices, for instance. And if it's a new customer, then that data is
input in real time.

I know my inlaws could now get much of the data for their music
database, but I've never looked at how to do it. Their system also
includes their own filing system, to know where to find a particular CD.

Post by Mayayana
It gets worse. I just drove home on roads today built
by others. I didn't forge a new one. I'm shameless.
On the bright side, the original ZIP code work was
probably not done by exploited, underpaid lackeys but
rather by postal service workers who get paid more
money and get better benefits than either you or I --
salary and benefits that come out of my taxes and
stamp purchases. The postal service is not technically
US gov't, but gov't data is supposed to be free by
law. (Nice to know. It means that you can use NASA
photos roylaty-free, for any purpose you like. Because
we taxpayers paid for them.)

The data input was more likely done by contract, or even college interns
if the PO used them.

Post by Mayayana
As I described earlier, I don't typically need a
database with data entry/edit functionality. My
email database is editable, but adding the email
is automated by a script(s). My geo-location
database was created using free data provided
by MaxMind.com. My ZIP code database, as noted,
was created quickly, using an existing list as CSV
file.

It does seem that your database needs are not the norm for most people,
since most people will be continually adding new info.

Post by Mayayana
If I were making a database for someone's music
collection I'd probably also try to automate it. A
day of coding scripts to walk 1,000s of MP3s and
parse their headers/names seems easier to me than
spending 3 weeks doing it by hand.

But, no MP3s at that time. All were retail CD's, and the file format is
not MP3.

Post by Mayayana
The only database I've ever needed that I wanted
data entry functionality for is the one I made for a
customer list. That one is so simple, and relatively
small, that it doesn't even have tables. It just uses
10-line software purchase "records" separated by
***, in a plain text file. Basic string searching
methods are adequate for the functionality.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Apd

2018-06-06 23:58:21 UTC

Post by Mayayana
| To build on Apd's explanation, when you request information via a query,
| and it pulls the answers from multiple tables, it's relational.
See the Wikipedia link. The *multiple* tables
is not relevant to it being relational. Apd showed
an example of a database that really benefits from
multiple tables, but the relationships between data
don't differ between that and a single table. Only
the query details will vary.

I know the wiki article says "one or more tables" but it then defines
relationships as "a logical connection between different tables".

I wouldn't call a single table a relational database, although it may
be part of one. However, a single table in a relational database is
called a relation!

See:
https://en.wikipedia.org/wiki/Relation_%28database%29
if you want to be confused ;)

Wolf K

2018-06-05 19:13:15 UTC

[]
I'm trying to understand what "relational" actually _means_ here. Rather
than just asking, I did try to look at the wikipedia entry, but it made
my brain hurt ...
I _think_ it means data that's crosslinked in various ways. (I do
genealogy, and I think the software I use is a relational database.) But
this makes me wonder what a _non_-relational database would _be_, other
than some sort of list or table.

This is how I understand it:

A relational database structures the data into linked sets and subsets,
so that any item is automatically linked to all members of whatever sets
it's a member of via the first link entered. This simplifies both data
entry and data query. That is, if new item X is member of set {R}, then
it's also a member of subsets {R'}, {R"}, {...} That membership does not
have to be explicitly stated.

As in genealogy: When you enter new item "John Doe" as "Son of James
Doe", the database will list John Doe as a child of James Doe {R}. It
will also show John Doe as sibling of all James Doe's children {R'}. Or
half sibling {R"}, if they have different mothers. You can also find all
John Doe's cousins (if any) on father's and/or mother's side {R1, R2}. Etc.

In a flat database, you'd have to explicitly enter both John Doe as a
son of James Doe, and James Doe as the father. More data entries, IOW.
Same as (half-)sibling of each of James Doe's children. Basically, a
flat database is a collection of lists. So you can think of a relational
database s a collection of linked lists.

Relational databases are not simple to construct, since for any given
pile of related data, there are many possible classifications. It all
depends on what the database is for. That's why switching from one
product to another usually requires major rewriting of the data-entry
forms. And that's why database software is big business.

--
Wolf K
kirkwood40.blogspot.com
Ethics is knowing the difference between what you have a right to do and
what is right to do. Potter Stewart

Ken Springer

2018-06-05 23:02:07 UTC

<snip>

Post by Wolf K
Relational databases are not simple to construct, since for any given
pile of related data, there are many possible classifications. It all
depends on what the database is for. That's why switching from one
product to another usually requires major rewriting of the data-entry
forms. And that's why database software is big business.

Definitely not easy to construct, so when the database is small enough,
a relational database makes no sense if you have to include a learning
curve.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Steve Hayes

2018-06-06 03:26:09 UTC

On Tue, 5 Jun 2018 19:13:30 +0100, "J. P. Gilliver (John)"

[]
I'm trying to understand what "relational" actually _means_ here. Rather
than just asking, I did try to look at the wikipedia entry, but it made
my brain hurt ...
I _think_ it means data that's crosslinked in various ways. (I do
genealogy, and I think the software I use is a relational database.) But
this makes me wonder what a _non_-relational database would _be_, other
than some sort of list or table.

A relational database is one that links several tables so that you can
save space for repeating data.

Lineage-linked genealofy programs are relational. RootsMagic, for
example, uses SQLite, and Legacy uses the Jet engine used by MS
Access, so if you wanted to you could do other stuff with your
database using Access or SQLite.

In these programs you enter every person once, and there are linking
tables that link the persons to spouses, children etc.

In a non-relational database (also sometimes called a "flat file"
database), you would enter a person with their spouse and children,
but then would have to re-enter all those names for each record of
each person.

Non-relational databases are much easier to set up and use, and are
often much more flexible in the kind of data that they can contain and
you can seach for.

I use two "large-text" databases for genealogical and other research,
Inmagic and askSam. askSam is particularly good for dumping large
amounts of disparate informnation and finding it again, so it is
useful for raw material for research. Inmagic is more structured, but
still more flexible than a relational database. I've used it, for
example, to index family letters, typing in extracts or summaries of
intormation from hard-copy letters people sent me. These often refer
to several people, and if you saved them in a relational genealogy
prtogram you'd actually end up with more duplication than you would in
a "flat-file" database.

Here's an example of an Inmagic report:

From: Pearson, Ralph
To: Steve & Val Hayes
Date: 8-Jul-1992
Had a letter from Mrs Anne Roberts in Carlisle who had
connections with the Vipond family, and also Jeanne Shapcott
of Queensland, who was descended from the Viponds of
Garrigill. He was also in touch with a West Cumberland
historian who had information about the Peile family of
Parton. May Pearson, his father's second wife, died on
16-Sep-1991. She was born on 14 Oct-1904. Gerald Elston (son
of Edith Pearson) died on 14-Dec-1991. Charles Arthur
Pearson (son of Charles Pearson) died on 5 Jan 1992. Sends
account of the life of Daniel William Pearson (his
grandfather). Had included something on Daniel's wife, Sarah
Jane Walker, and about "Wonderful Walker", whose connection
with the Walkers of Whicham may have been tenuous. Was
researching Cecil William Pearson, son of Charles. He had
joined the Northumberland Fusiliers (4th Battalion), but
later volunteered for the Royal Flying Corps, and was killed
on 3 Jan 1918 while serving with 57 squadron as an observer.
Was buried at Amerika, close to Ten Brielen in Belgium.
Grandson Kevin had graduated from Cubs to Scouts.

My search argument for that was "peile w3 parton" (Peile within three
words of "Parton"). Putting that kind of stuff in a lineage-linked
program is actually more difficult.

Hope this helps.

--
Steve Hayes
http://www.khanya.org.za/stevesig.htm
http://khanya.wordpress.com

J. P. Gilliver (John)

2018-06-06 06:13:13 UTC

In message <***@4ax.com>, Steve Hayes
<***@telkomsa.net> writes:
[]

Post by Steve Hayes
A relational database is one that links several tables so that you can
save space for repeating data.

I'm sure that there is more to the linking than just the saving of
space. (Especially nowadays, when wasting space seems almost
obligatory.)
[]

Post by Steve Hayes
still more flexible than a relational database. I've used it, for
example, to index family letters, typing in extracts or summaries of
intormation from hard-copy letters people sent me. These often refer
to several people, and if you saved them in a relational genealogy
prtogram you'd actually end up with more duplication than you would in
a "flat-file" database.

[]
The one I use (Brother's Keeper) lets me link to files; in the case of a
letter like the one you quoted, until I'd parsed all the individual
facts in it, I'd just put the letter in a file, and link all the people
it refers to to that one file. When I had time, I'd extract facts from
it and file them under the affected persons, with the source credited -
I can link a single "source" to lots of facts. (I would also remove the
facts from the original as I went, until I'd eventually got it down to
nothing, then delete it, with the individual facts - with extracts if
necessary - filed under the people they refer to, and citing it from the
list of sources [which are a flat file]; that's just me, and I know some
people would keep the full original text file even once they'd copied
the facts it contained to more appropriate places.)

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

But remember, in a permissive society, it is also permissible to stay at home
and have a nice cup of tea instead. Andrew Collins, RT 2015/2/14-20

Mayayana

2018-06-06 12:45:37 UTC

"J. P. Gilliver (John)" <G6JPG-***@255soft.uk> wrote

| >A relational database is one that links several tables so that you can
| >save space for repeating data.
|
| I'm sure that there is more to the linking than just the saving of
| space. (Especially nowadays, when wasting space seems almost
| obligatory.)

From Wikipedia:
"A relation is defined as a set of tuples (records) that have the same
attributes. A tuple usually represents an object and information about that
object. Objects are typically physical objects or concepts. A relation is
usually described as a table, which is organized into rows and columns."

So relational and table-based are the same thing.

I'm beginning to think there may be differences in
how people "know" databases. If someone is not
writing their own queries then the structure of the
database depends on how the front-end is designed.
If the front-end is designed to avoid repetitive entry
that makes for easier usage, but it has no direct
relationship to the backend.

Also according to Wikipedia, a relational database
is composed of *one or more tables* and virtually
always uses some form of SQL. So it seems the
table structure *is* the relation, in that each record
has the same fields.

I use databases to create custom storage for large
amounts of specific data. My old emails, for instance.
I haven't yet found a good reason to make a database
with more than one table. And so far no one here has
offered a real world example of how multiple tables
are an advantage except when there are simply too
many data points to fit into a single table realistically,
or where the data usage is extreemely complex.

For example, Customer and Address tables, as Ken
showed, allow a Customer.Address field to link to
an entire set of data in an Address table. That's good
organization, but it's also less efficient and takes *more*
space than putting it all in one table, if only for the fact
that each table will need an extra field. Customer needs
a field that links to Address and Address needs a unique
key field for that access. And both tables will have to be
loaded in memory in order to look up someone's street
address.
On the other hand, a separate table to store pictures
of a customer from store security cameras would make
sense because that gets into non-primary data that's
bulky.

This has also got me to thinking about possibilities.
I generally think about how to store data, access
it in a practical, easy way, and allow for backup.
(A database is no good if it's stored in some kind
of proprietary file type that will be gone in 5 years.)
I suppose most people use it that way.

But then there's also analysis, which seems to be
a big part of database usage in business. Cambridge
Analytica must have done a lot of work to collect
87 million Facebookie profiles. But what's far more
impressive is that they figured out ways to analyze
the data, in order to [allegedly] plan specific news
items for specific people in order to mold their
political opinions.

Likewise, Google must use very complex databases
to organize the disparate bits of personal data their
spyware collects. But the impressive part is that they
can then analyze that data to decide which ad you
should see when visiting a travel agent website. (Just
as the travel agent uses data to decide what price
you should be offered for your plane flight.)

I'm imagining armies of geeks writing wildly complex
queries all day, trying to come up with profitable
data... Do 17-23 y.o. blue collar, male Facebookies
like Bud or Bud Light more? How about 24-30 y.o.?
What if their girlfriends drink Kahlua? What if their
Facebook friends are predominantly college educated?
And of the men who prefer Bud Light, how many will
be interested in frozen pizza sold under the Bud
brand?
(An intriguing aspect of that is the mechanistic
limitation. No one then asks, "What if the pizza actually
tastes good?". They can't ask that. It's a subjective,
qualitative judgement. They'll market the pizza to a
frame of mind, using brand recognition and trigger
concepts ("lo-cal", "with real tomato flavor!", "official
frozen pizza of the Olympics", etc) to hook in the
purchase. The actual product will be secondary.
Sounds nuts, but that accounts for most of the pre-
packaged food in supermarkets. No one in their right
mind, who actually tastes their food or compares prices,
would buy most of that stuff.
....Well, OK, a frozen pizza-esque product that can
be microwaved in 15 seconds, composed of mainly
hydrogenated palm kernel oil, alleged wheat flour that
"fell off a truck" and fake cheese flavor, with extra
protein added, with caffeine to help burn off the calories,
with testimonials from Olympic skiers, and named
PowerFitnessPizza, would be a desirable, high quality
food. But the rest... :)

Ken Springer

2018-06-06 15:44:06 UTC

<snip>

Post by Mayayana
For example, Customer and Address tables, as Ken
showed, allow a Customer.Address field to link to
an entire set of data in an Address table. That's good
organization, but it's also less efficient and takes *more*
space than putting it all in one table, if only for the fact
that each table will need an extra field. Customer needs
a field that links to Address and Address needs a unique
key field for that access. And both tables will have to be
loaded in memory in order to look up someone's street
address.

Maybe I'm wrong, but I think you keep forgetting how many times you may
have to enter the exact same information multiple times.

What you need to have in the database all depends on what you need to know.

You have a customer named John Smith, who owns 5 hardware stores, and
has a separate business office location. Goods are shipped to the store
locations, the bills go to the business office.

If this info is all in one table, you will enter the business office
address 5 times, in each record for the store locations.

Same goes for every other customer you have with similar situations.
What if the customer has 1,000 store locations, built up over time, one
or two stores at a time. Want to enter the billing address s1000 times,
or just one time is a different table? :-)

<snip>

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

J. P. Gilliver (John)

2018-06-06 16:51:56 UTC

Post by Ken Springer
<snip>

[Why did you leave my attrib. line in, and then snip all that I said?
I'm not objecting, just wondering!]

Post by Mayayana
For example, Customer and Address tables, as Ken

[]

Post by Ken Springer
Maybe I'm wrong, but I think you keep forgetting how many times you may
have to enter the exact same information multiple times.

[]
Maybe _I_'m wrong, but I do think you're getting hung up on this
multiple-entry-of-the-same-data thing. In situations where this sort of
thing might be required, the _entry_ mechanism - such as a "form" -
should handle this problem, in at least one of two ways:

1. When you click OK or whatever to finish a record and start the next
one, the form does _not_ blank all the fields, so that if the next
record is for the same (say) customer, the relevant details are already
present; or

2. as soon as you enter (say) customer name/number in the relevant
field, the form/database retrieves (say) customer address for you. (With
variations, such as a "new" button so you can add a new customer with
the same name as an existing one, but who is actually a different
customer at, say, a different address.)

Both have pitfalls. 1. can result in duplicate line items appearing on
an order (if OK is clicked twice by mistake), or irrelevant data
appearing (I've encountered this when using Ancestry - UK census data
has been seen containing a "race" field, which it never did, presumably
because the transcriber switched to doing it after having done a US
census, without clicking the "clear all" button). 2. is tedious if the
_majority_ of your new records do _not_ contain much the same data as
the previous record, though ideally there should be a control somewhere
that switches between "autofill" and "autoclear". But having such input
forms - or macros, or whatever - should avoid the problem of having to
enter the same thing more than once. (And also help to make sure that
when it _is_ the same thing, it's entered with the same spelling,
capitalisation, punctuation, and so on.)

The genealogy software I use has several such shortcuts: if I put " in
the location cell for an event, it copies from the closest above event
that is actually a location (e. g. a born, resided, married, died, etc.,
but _not_ an occupation); if I put =, it duplicates the location for the
same event from the previous person I was editing. If I put the first
few characters of a location and press F8, I get a list of locations
I've already used that start with those characters (and it ignores case
in what I typed, but they're correct in the offered list). And so on.
Any data entry system worth its salt will have similar time-saving
mechanisms.

Ken Springer

2018-06-06 20:28:38 UTC

Post by Ken Springer
<snip>

[Why did you leave my attrib. line in, and then snip all that I said?
I'm not objecting, just wondering!]

I wasn't replying to anything you wrote, I was replying to what Mayayana
wrote following your comments. <G>

Post by Mayayana
For example, Customer and Address tables, as Ken

[]

Post by Ken Springer
Maybe I'm wrong, but I think you keep forgetting how many times you may
have to enter the exact same information multiple times.

Yes, it *should* handle it. But that doesn't guarantee that it does
handle it, or the user knows how to create a form to do it. And in that
case, you'll get to type it every time.

Either way, the extra data will still take up the space on the hard drive.

Post by J. P. Gilliver (John)
1. When you click OK or whatever to finish a record and start the next
one, the form does _not_ blank all the fields, so that if the next
record is for the same (say) customer, the relevant details are already
present; or

That's the way I set up the form in the music database years ago.

Post by J. P. Gilliver (John)
2. as soon as you enter (say) customer name/number in the relevant
field, the form/database retrieves (say) customer address for you. (With
variations, such as a "new" button so you can add a new customer with
the same name as an existing one, but who is actually a different
customer at, say, a different address.)

Yep, but we don't know the user knows how to do this.

Post by J. P. Gilliver (John)
Both have pitfalls. 1. can result in duplicate line items appearing on
an order (if OK is clicked twice by mistake), or irrelevant data
appearing (I've encountered this when using Ancestry - UK census data
has been seen containing a "race" field, which it never did, presumably
because the transcriber switched to doing it after having done a US
census, without clicking the "clear all" button). 2. is tedious if the
_majority_ of your new records do _not_ contain much the same data as
the previous record, though ideally there should be a control somewhere
that switches between "autofill" and "autoclear". But having such input
forms - or macros, or whatever - should avoid the problem of having to
enter the same thing more than once. (And also help to make sure that
when it _is_ the same thing, it's entered with the same spelling,
capitalisation, punctuation, and so on.)

This is where most computer users begin to piss me off. LOL They don't
want to know if there's an easier and quicker way to enter data, such as
using forms.

So, when I write in threads like this, I look at everything at the
lowest common denominator, in this case you repeatedly enter the same
data over and over.

But eventually, I think a little bit of "familiarity breeds contempt",
or something. Like Mayayana seemingly not considering that someone
input all 55,000 records that he was able to use en masse.

If you stop to think about it, seems fairly obvious that any data you
obtain and use was input by some human at some point in time.

Post by J. P. Gilliver (John)
The genealogy software I use has several such shortcuts: if I put " in
the location cell for an event, it copies from the closest above event
that is actually a location (e. g. a born, resided, married, died, etc.,
but _not_ an occupation); if I put =, it duplicates the location for the
same event from the previous person I was editing. If I put the first
few characters of a location and press F8, I get a list of locations
I've already used that start with those characters (and it ignores case
in what I typed, but they're correct in the offered list). And so on.
Any data entry system worth its salt will have similar time-saving
mechanisms.

At least, it should. LOL And, you took the time to learn those
shortcuts, but how many people don't bother to learn how to use the
software, and thus don't know the shortcuts?

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-06 21:46:54 UTC

"Ken Springer" <***@greeleynet.com> wrote

| Maybe I'm wrong, but I think you keep forgetting how many times you may
| have to enter the exact same information multiple times.
|
| What you need to have in the database all depends on what you need to
know.
|
| You have a customer named John Smith, who owns 5 hardware stores, and
| has a separate business office location. Goods are shipped to the store
| locations, the bills go to the business office.
|
| If this info is all in one table, you will enter the business office
| address 5 times, in each record for the store locations.
|
I see the advantage in terms of space. Apd's example
showed that well. But in a real world case you probably
don't save or add work. Regardless of how the tables
are set up, you'll need to enter John Smith's name at the
checkout counter. You probably don't know his customer
ID, so you'll also have to enter his address or phone #.
You'll have to keep on until there's enough data entered
to ID him uniquely. So having multiple tables might save
you from having John Smith's name and address entered
numerous times. That's good. But it won't do anything to
simplify your data entry or improve the usefulness of
the database.

I think it also has to be noted that an example like Apd's
assumes automation. For that matter, databases assume
automation. Customer IDs and product IDs are
not useful to humans. So what you're really talking about
is a checkout scanner that fills in the purchase info and
clerk input that brings up the right customer account.

At my local lumberyard they have a system of "account
numbers". I give them my account # and they automatically
then charge the sale to my account and record the
purchase as mine. If I know my account#. Otherwise they
have to start searching via name, phone#, etc. None of
that will be easier or harder with multiple tables. It will
only be stored more efficiently. Which is nothing to sneeze
at, I agree. I'm only questioning the assumption that
multiple tables are necessarily more efficient or flexible
in functionality.

Ken Springer

2018-06-07 02:29:26 UTC

Post by Mayayana
| Maybe I'm wrong, but I think you keep forgetting how many times you may
| have to enter the exact same information multiple times.
|
| What you need to have in the database all depends on what you need to
know.
|
| You have a customer named John Smith, who owns 5 hardware stores, and
| has a separate business office location. Goods are shipped to the store
| locations, the bills go to the business office.
|
| If this info is all in one table, you will enter the business office
| address 5 times, in each record for the store locations.
|
I see the advantage in terms of space. Apd's example
showed that well. But in a real world case you probably
don't save or add work. Regardless of how the tables
are set up, you'll need to enter John Smith's name at the
checkout counter. You probably don't know his customer
ID, so you'll also have to enter his address or phone #.
You'll have to keep on until there's enough data entered
to ID him uniquely. So having multiple tables might save
you from having John Smith's name and address entered
numerous times. That's good. But it won't do anything to
simplify your data entry or improve the usefulness of
the database.

I notice more and more systems/clerks simply ask for your phone number.
The equivalent of your loyalty card. And the systems seem to default to
the local area code, as I just give them my 7 digit phone # and we're
off and running. After that, they just scan the item. And, of course,
I slide my card through the scanner. <G>

The only time the clerk spent any time entering my data was when I
"signed up" at that store.

Post by Mayayana
I think it also has to be noted that an example like Apd's
assumes automation. For that matter, databases assume
automation. Customer IDs and product IDs are
not useful to humans. So what you're really talking about
is a checkout scanner that fills in the purchase info and
clerk input that brings up the right customer account.

I suspect that a lot of stores access the info on your credit card
and/or loyalty card, too. Grocery, department stores, etc.

Post by Mayayana
At my local lumberyard they have a system of "account
numbers". I give them my account # and they automatically
then charge the sale to my account and record the
purchase as mine. If I know my account#. Otherwise they
have to start searching via name, phone#, etc. None of
that will be easier or harder with multiple tables. It will
only be stored more efficiently. Which is nothing to sneeze
at, I agree. I'm only questioning the assumption that
multiple tables are necessarily more efficient or flexible
in functionality.

For me, it seems it's either the physical loyalty card, or my phone #.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Mayayana

2018-06-07 13:22:26 UTC

"Ken Springer" <***@greeleynet.com> wrote

| > At my local lumberyard they have a system of "account
| > numbers". I give them my account # and they automatically
| > then charge the sale to my account and record the
| > purchase as mine. If I know my account#. Otherwise they
| > have to start searching via name, phone#, etc. None of
| > that will be easier or harder with multiple tables. It will
| > only be stored more efficiently. Which is nothing to sneeze
| > at, I agree. I'm only questioning the assumption that
| > multiple tables are necessarily more efficient or flexible
| > in functionality.
|
| For me, it seems it's either the physical loyalty card, or my phone #.
|

What a trusting soul. I find those requests so rude
that I don't even answer them anymore. If I'm
in a good mood I just say , "No". If I'm in a
bad mood I say, "None of that stuff! I just want
to buy the thing!"

I have an account with the lumber yard because
I'm a contractor and [allegedly] get discounts. At
the least, I get better treatment as a known regular
customer. I would never give info to other stores
and pay cash when possible.

It started with dept store clerks casually asking,
"Phone number?", as though that were a normal
question for a retail purchase. (I think you're
right about that. Asking for phone number is a
discreet way to have their computer rifle through
your personal life. It doesn't seem so intrusive
as asking for each bit of personal info.)

And it just keeps getting worse. Some stores now
want me to actively push buttons to confirm that
I don't intend to cooperate with their sleazeball
datamining. And they warn me with theatrical
gravity that if I refuse to submit then I'll need
my receipt if I need to return anything!

For a while stores with loyalty cards were
selling at the same price to non-card-holders.
I figured it must be a legal thing. But then they
stopped. Are they breaking the law? Did the
law change? Are they paying off my Republican
governor to look the other way? I have no idea.
But when CVS is charging $12 for disposable
razors or $6 "with card", I'll just go somewhere
else. The problem with these scams is that
eventually they'll come full circle: You'll have
to let them track you in order to get the price
you used to pay without tracking.

On the other hand, you get special service that
I don't get. There's probably some software,
someplace, rigged to send you a text-message
coupon for every brand of toothpaste you don't
use, on the day you current tube runs out. So
there's that. :)

It still surprises me that people so passively
accept these intrusions. Like the Facebook
controversy: People are shocked that device
companies have access to personal data. Well,
yeaaah.... That's the least of it. Google have
teamed up with credit card companies while
also using spyware on phones, to record and
analyze what you see/click online, where/when
you go to shop, and what you buy. They use all
that as evidence to justify maximizing their
adwords fees. Yet somehow the excited and
outraged Congressmen raging at Zuck have
managed to not be aware of that.

Few are motivated to actually stop cooperating
with this sleaze epidemic, even when they're
told about it. There seems to be an old-fashioned
assumption of community. A kind of community
that no longer exists. Where people are basically
ethical and must answer to their neighbors if
they're not. And where laws regarding common
decency prevent exploitation.

There was an interesting case back in 2012,
where Target started sending ads to a teenage
girl for pregnancy-related products. The father
got mad and complained. Then he found out
that his daughter was, indeed, pregnant. He
hadn't known, but Target did. Oddly, he apologized
once he'd confirmed it. It never occurred to him
to question the propriety of such deep datamining:

http://webcache.googleusercontent.com/search?q=cache:kaaH3nB20GYJ:https://www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-was-pregnant-before-her-father-did/%2B%22www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-was-pregnant-before-her-father-did/%22&lr&hl=en&as_qdr=all&gbv=1&ct=clnk

That's a Google cache link. Ironically, Forbes
will no longer let you see their website at all unless
you join up, allow them to track you, and let them
control your browser.

Even the Target case is tame compared to what
the likes of Google and Facebook are doing.

Meanwhile, the Internet is mirroring retail stores.
Websites try to force you to ID yourself and allow
them to perpetrate a "push" campaign against you,
in exchange for letting you see their webpage
content. If they can't track you, spy on you,
target ads at your personal interests, control
your browser, and send push notifications, then,
as with Forbes.com, you're not welcome at their site.
This has all come about in large part because people
cooperate at each step in the process.

See all the trouble your damned databases
have caused? :)

Ken Springer

2018-06-08 03:41:50 UTC

Post by Mayayana
See all the trouble your damned databases
have caused?:)

LOL!!!!

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Steve Hayes

2018-06-07 04:58:15 UTC

On Wed, 6 Jun 2018 07:13:13 +0100, "J. P. Gilliver (John)"

Post by Steve Hayes
A relational database is one that links several tables so that you can
save space for repeating data.

I'm sure that there is more to the linking than just the saving of
space. (Especially nowadays, when wasting space seems almost
obligatory.)

Yes.

It also saves one from having to reenter data multiple times, and
makes it easier to link the data in various ways.

But by doing that you can miss the opportunity to find important
research hints.

That can be done in a relational database, depending on the design --
and the main DISadvantage or relational databases is how much time has
to be spent on design, and how changes in design are also awkward and
time-consuming.

But keeping source data in a "flat-file database can make it possible
to find new connections between old data as new data are added.

--
Steve Hayes
http://www.khanya.org.za/stevesig.htm
http://khanya.wordpress.com

Nil

2018-06-05 01:36:24 UTC

Post by Ken Springer
Open source would be my first preference, but not mandatory. I
know Libre Office and Open Office have Base, but my impression is
that program is in the Access category of software.

I've never been able to make a usable database with Libreoffice Base.
As far as I can tell, you have to create a database in MySQL or another
format and Base is merely the front end to it.

I miss Access.

Ken Springer

2018-06-05 03:18:42 UTC

Post by Ken Springer
Open source would be my first preference, but not mandatory. I
know Libre Office and Open Office have Base, but my impression is
that program is in the Access category of software.

I've never been able to make a usable database with Libreoffice Base.
As far as I can tell, you have to create a database in MySQL or another
format and Base is merely the front end to it.

This has always been my understanding, but I think there's been some
changes lately, that give you some database capabilities without having
to use MySQL or another database.

Post by Nil
I miss Access.

I might if I had need for the level of capabilities of Access. But for
my current needs, it would be like using a Peterbilt tractor and a 40'
flatbed to haul the weekly trash to the dump station.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Nil

2018-06-05 17:48:17 UTC

Post by Nil
I've never been able to make a usable database with Libreoffice
Base. As far as I can tell, you have to create a database in
MySQL or another format and Base is merely the front end to it.

This has always been my understanding, but I think there's been
some changes lately, that give you some database capabilities
without having to use MySQL or another database.

You may be right. I may have noticed an new "native" or self-enclosed
database engine available in Base as well as being a front end for
other databases. But it was all very confusing and poorly documented.
I've gone back a few times and gotten frustrated and annoyed and given
up. I'm sure I'll give it another crack one of these days.

Post by Nil
I miss Access.

I might if I had need for the level of capabilities of Access.
But for my current needs, it would be like using a Peterbilt
tractor and a 40' flatbed to haul the weekly trash to the dump
station.

I found Access ideal for both small and large projects. It's only the
cost that makes it overkill for most of us. I built several large
database utilities with it for work many years ago and it was very
solid and reliable and fun to work with. I also made little database
programs for myself at home to keep track of my music collection,
addresses, and other things. However, after Access 2003 I could never
justify the price. I get the feeling Microsoft eventually lost interest
in it and I don't hear it spoken of much anymore.

I haven't found another relational database product with that
combination of power and user friendliness.

Ken Springer

2018-06-05 23:06:19 UTC

This has always been my understanding, but I think there's been
some changes lately, that give you some database capabilities
without having to use MySQL or another database.

Given the small size of my project, tackling Base totally isn't worth
the time.

Post by Nil
I miss Access.

I might if I had need for the level of capabilities of Access.
But for my current needs, it would be like using a Peterbilt
tractor and a 40' flatbed to haul the weekly trash to the dump
station.

I think MS may have made it so complex and powerful only large
businesses want to tackle using it. Mom and Pop businesses didn't have
the time and resources to spend.

Now, so many use a spreadsheet for non-relational purposes, and quite
possibly to their detriment since they can't track and manipulate that
many disparate items of information.

Post by Nil
I haven't found another relational database product with that
combination of power and user friendliness.

--
Ken
Mac OS X 10.11.6
Firefox 59.0.1 (64 bit)
Thunderbird 52.6.0
"My brain is like lightning, a quick flash
and it's gone!"

Nil

2018-06-06 06:15:06 UTC

Post by Ken Springer
Given the small size of my project, tackling Base totally isn't
worth the time.

Actually, I spent a little time with Base today and was actually able
to create a database! I'm encouraged to work with a little more now.

Post by Ken Springer
I think MS may have made it so complex and powerful only large
businesses want to tackle using it. Mom and Pop businesses didn't
have the time and resources to spend.

I can only speak about Access 2003 and earlier, but unless Microsoft
really screwed it up later, I found it to be quite easy. Basic tables
and queries are simple. Relating tables, should you need and understand
the concept, is easy to do. Creating forms is somewhat more complex.
Macros, scripting, and code is more so, but still more straightforward
than other database programs I've used. It can get as complex as you
want, but the basics are easy and easy to get to. I find it easier than
Excel.

Post by Ken Springer
Now, so many use a spreadsheet for non-relational purposes, and
quite possibly to their detriment since they can't track and
manipulate that many disparate items of information.

Both have their uses and those uses can overlap. I find that Access
can do more Excel-like things than Excel can do Access-like things.
That said, I find myself using Excel more than Access these days for
some reason. I guess my needs are simpler than they used to be.

Ken Springer

2018-06-06 15:29:22 UTC