Onno (VK6FLAB)

@ vk6flab @lemmy.radio

Posts

50
Comments

1878
Joined

2 yr. ago

Anything and everything Amateur Radio and beyond. Heavily into Open Source and SDR, working on a multi band monitor and transmitter.
#geek #nerd #hamradio VK6FLAB #podcaster #australia #ITProfessional #voiceover #opentowork

14h ago

is it true that linux cannot run on a laptop without any SSD ?
Jump
Onno (VK6FLAB) @lemmy.radio 14h ago
Also trying to sell you something .. potentially on commission.

22h ago

Open-Source z386 Brings Intel 80386 Microcode Back to Life

Here you go:

While databases have struck fear in the hearts of many developers, it's really just a structured way of storing (sometimes large amounts of) information.

From a naming perspective, a database is essentially a collection of tables, each of which you can think of as a simple list of rows, each row containing a collection of fields, each not unlike a single spreadsheet with a label at the top of each column.

Like a spreadsheet, you can decide what types of values are permitted in each field (column).

In spreadsheets you can refer to a row by its row number, which breaks down as soon as you sort a sheet, database tables can similarly be ordered, or not, depending on the requirements.

A query returns one or more rows as required.

You can relate two tables if you want to by having both tables have a field with the same definition and value, and then query the information together, linked by that common field. You can link many tables together if your data requires it.

For example, you might have a list of job types, with information that's specific to each job of that type. By storing those types in their own table, you don't need to duplicate the information for every single job stored in another table.

Essentially that's pretty much all there is to it.

If you get into bigger and more complex stuff, you'll come across a thing called an index, which tracks one or more field values across one or more tables, for the purpose of making retrieval faster, but until you hit a thousand rows, you're unlikely to need them.

Disclaimer: This is a summary of 40+ years of database experience and it's purposefully written to simplify concepts. It doesn't get into different database engines, but at this stage that likely won't matter much.

The underlying purpose of a database is to ensure data integrity, in other words, to make sure that a telephone field contains a telephone number and not an email address by accident. It's also intended to minimise the amount of data duplication and associated resource use, like memory, disk and network. Finally it provides mechanisms for multiple simultaneous users and associated conflicts.

Have fun!