How can I create a database with grams and onzes

users
#1

please send me details how can I create a databese using measurements, for example, grams, onzes, etc.
Thanks
Emilia Morales8095290730

#2

Hi Emilia,

The obvious answer is: the same way you create any other database.

I'm afraid that if you want a more specific answer, you're going to
have to ask a more specific (and detailed) question.

Paul

#3

Well those are units, but the database, I assume, will be storing
integers, or even doubles, decimals or float values depending on your
database backend. You need to think about what it is you are trying to
store as information before worrying about the units, these can be dealt
with as field labels, aliases, or even calculated fields or views.

Alex

#4

Hi :slight_smile:
There are some video tutorials, a handbook and an Faq section on our wiki.
There are probably YouTube videos and other 3rd party resources which
might also be useful

"Spoken Tutorials" search results for Base in English
http://www.spoken-tutorial.org/list_videos?view=1&foss=LibreOffice-Suite-Base&language=English
Note they cover a wide range of other FOSS tools.

The Base Handbook (translated from the original in German into English)
https://wiki.documentfoundation.org/Documentation/Publications#LibreOffice_Base_Handbook
Given the way you asked the question i suspect you might find the 3
chapters of the full Base Guide useful.

The Faq section about Base (translated from the original French into
English)
https://wiki.documentfoundation.org/Faq/Base

Databases are more more complicated to think about than spreadsheets but
tend to be much more robust. If you sort the data in a spreadsheet it
often 'sorts' 1 column only which then makes all the data in that column
out-of-sync with the rest. For example a spreadsheet of 3 rows and 3
columns might look like this
Mr William Isaacs
Mrs Toshie Sato
Miss Julie Walters
Most people sorting by first name (in spreadsheet) would get
Mr Julie Isaacs
Mrs Toshie Sato
Miss William Walters
With a database the entire rows would have been moved around to keep the
information in each row unchanged. William wouldn't have suddenly become
female.

They are more complicated because they have a "back-end" and a "front-end".
The data itself is kept in tables in the "back-end" but you view it
through the front-end. So when you are sorting data it's only the
front-end view that you are modifying. Other people accessing the back-end
see the data unchanged and can do different "sort"s, for example;
person B might want to see the list in surname order and
person C might want to split males split from females.
All 3 can save their front-end views and return to them another day.
Person A might have added another couple of names in between times. So
when person B opens their front-end again they see 5 names in surname
order.

To be really useful the back-end is often a separate program with it's
tables stored on a server which other people can reach. However some
database programs have the back-end built into the same program you use for
the front-end and then that database is kept on 1 desktop machine. This
makes it really difficult for more than 1 person at a time to access the
data. It's the way Microsquish Access works by default. Base prefers if
you use a separate back-end. When you try to open Base for the first time
one of the first questions it asks you is where the back-end is.

To start with you might find it easier to use Base's own internal back-end
but it's not a good idea to stick with that for very long. In the longer
term it would be wise to move it to an external database program such as
MySql/MariaDb, PostgreSQL or one of many other choices. Each has it's
advantages. Some are made for small amounts of data, such as the average
address book, while others might be better for vast amounts of data.

The "front-end" is also in 3 parts; Queries, Forms and Reports.
Queries are the best place for doing sorts, filtering, combining data from
different tables but their output doesn't look very nice. They look like
spreadsheet tables.
Forms and Reports are good for taking the output of the Queries and
presenting them in more attractive or easier to read ways. They can also
do a bit of sorting and filtering but that is best avoided except for
quick, temporary things otherwise you start to lose track of what is going
on where. Make the Queries do most of the work so that you know where to
go when you need to fix things.

Forms are probably the best way for normal users to enter data into the
database but as the designer you will probably find yourself entering
directly into tables or maybe using Queries.

Base often allows you to use Writer and/or Calc as the Forms and Reports
because the whole of LibreOffice is 1 integrated whole, rather than being
separate programs (OpenOffice is designed the same way, of course). So,
normal users are able to look through the data using familiar tools instead
of having to learn a whole new interface for a whole new program. I think
they can't enter data that way but at least they can look-up the current
contents.

So, it's all a lot more complicated to think about but once you have built
one you will see how much more powerful it is and how much easier it is to
work with the data even just for a single user.
Regards from
Tom :slight_smile: