I am not an expert in the SQL and database in general.
I am creating an android application with the feature of multi-languages for both the interfaces and the content itself.
my question is for the content language: is there any way to retrieve data from the database which is containing only one language (English),like translating the content to the other language option ??
because I think it is not efficient to store both languages in the database.
thanks in advance,
Text belonging to the client app is usually stored with that app, so you don't have to load "OK" and "Cancel" in the appropriate language from database only to show some buttons. (But you could store this in a database of course, if you wanted to.)
Content data on the other hand is usually stored in the database. It doesn't make much sense, to store part of it in the database and part of it somewhere else. If you store products in your database, then store the text necessary with it. It belongs there. As to accessing data, this is not slow, because you don't retrieve text in all languages, but only in the language desired.
Here is a typical table design:
create table product
(
id number(10),
buying_price number(6,2),
selling_price number(6,2),
id_vat number(1),
...
);
create table product_name
(
id_product number(10),
language_iso varchar(2), -- 'en', 'de', 'fr', ... or chose another code
text varchar(100)
);
create table product_description
(
id_product number(10),
language_iso varchar(2),
text varchar(2000)
);
You could also decide for a more generic design:
create table products
(
id number(10),
tranlation_number number(10),
buying_price number(6,2),
selling_price number(6,2),
id_vat number(1),
...
);
create table translations
(
tranlation_number number(10),
content_name varchar2(30), -- 'PRODUCT_NAME', 'PRODUCT_DESCRIPTION', ...
language_iso varchar(2), -- 'en', 'de', 'fr', ... or chose another code
text varchar(4000)
);
There are more possibilities. Whichever you chose, accessing data simply means a join and a constant for the language. There should be no problem with performance at all. And data is where it belongs.
Related
I put my data in 3 tables(Links, Images and PDF)
each table has columns(university, faculty, grade, and description,...)
I want to retrieve description column in the 3 tables.
where university, faculty, and grade equal to certain values.
and sort them with creation date.
how can I perform that query in parse?
I'm not familiar with Android, but I'm pretty sure Parse does not support "Join" in the way a SQL database does. You could nest the queries, performing the next one in the previous one's completion block.
However, if you regularly want to get data from those 3 tables, I'd suggest you make it 1 table instead, with a column "Content" instead of Link/Img/PDF. Images and PDFs would probably be stored as PFFiles anyway, and you can put link as either its own string column or putting it in a file. You could also add a column "type" if you want to be able to query a specific type, or just keep track of which columns contains which data.
Then you could query the "Content" class, on the keys you want.
I think this link might help you
https://parse.com/docs/js/guide#relations and it is quite simple and nicely explained . You can't do it directly in the database, though.
For my Android app, I want to save data using sqlite with this format:
name, date, attr1, attr2, attr3,...
These are the requirements:
each date can only contain each name once
there can be a variable number of attributes(numbers) for each name
each specific name has the same number of attributes
The app will be used to track events throughout the day. Events can have zero or more numeric properties.
The questions are: is sqlite the best way to store things here? If so how do I design my database? What other ways are there to store this kind of data?
is sqlite the best way to store things here?
This will depend on a number of other factors, such as how the data will be queried and used, the volume of transactions, data growth and retention, etc. From what you've described, though, SQLite is a great option, offering functionality out-of-the-box that supports some of your requirements directly, and is commonly used in such cases.
If you don't have much experience with relational databases, implementing this functionality may seem difficult at first, but like learning a new language or framework, it will get easier with time.
If so how do I design my database?
Let's step through each of your enumerated requirements...
each date can only contain each name once
SQLite supports the UNIQUE constraint. For example, if your columns were named name and date, you could add the following to your CREATE TABLE statement:
UNIQUE(name, date)
(A more complete CREATE TABLE statement is in the next example below, and it includes this constraint.)
This constraint prevents the insertion of rows with name/date pairs that already exist. Using android.database.sqlite.SQLiteDatabase, if you attempt to insert a row into the table with a duplicate name/date pair, a SQLiteConstraintException will be thrown at runtime. You will need to handle this exception in your java code.
there can be a variable number of attributes(numbers) for each name
This is a textbook case for normalizing the database, putting your data into multiple tables. For example:
CREATE TABLE names (
name_id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
name TEXT NOT NULL,
date DATETIME,
UNIQUE(name, date));
CREATE TABLE attrs (
name_id INTEGER NOT NULL,
attr_value INTEGER NOT NULL,
FOREIGN KEY(attr_value) REFERENCES names(name_id));
Your queries that retrieve attribute data would then JOIN the two tables. Since you indicated that "Events can have zero or more numeric properties", a LEFT OUTER JOIN might be most appropriate, as it will return names and dates even if there are no attributes.
Here's an example query, by name:
SELECT n.name, n.date, a.attr_value
FROM names AS n
LEFT OUTER JOIN attrs AS a
ON n.name_id = a.name_id
WHERE n.name = 'SMITH'
ORDER BY n.name, n.date, a.attr_value;
This query would return results like the following:
name date attr_value
--------------- ---------- ------------
SMITH 2015-02-13 1027
SMITH 2015-02-13 4426
SMITH 2015-02-13 8390
SMITH 2015-02-20 4426
SMITH 2015-02-20 8152
SMITH 2015-02-20 9328
You can then iterate through and process these results in java. If your results include multiple names and/or dates, then in your loop you should keep track of the last used name and date. If the name/date in the current record is the same, the attribute belongs to the current one. If the name/date is different, then this is a new one.
Note that this approach to your database design is flexible, allowing you to query on the attributes, for instance, to see what name/date pairs are associated.
Also note that there is a FOREIGN KEY constraint on the attrs table, meaning that if you attempt to insert a record into that table with a name_id that does not exist in the names table, a SQLiteConstraintException will be thrown at runtime. You will need to handle this exception in your java code.
each specific name has the same number of attributes
You will need to accommodate this requirement in your java code, probably doing some checks in the database prior to performing an INSERT.
What other ways are there to store this kind of data?
Flat files, JSON, XML, third-party data stores (with their own libraries), to name a few.
I'm not sure but I think the best way to achieve your requirement is to use sqlite and to solve your problem you can have 3 columns only. One for the name and one for the date and the other contains a JSON array that represents the rest of the attributes.
this is more of a question of theory than anything else. I am writing an android app that uses a pre-packaged database. The purpose of the app is solely to search through this database and return values. Ill provide some abstract examples to illustrate my implementation and quandary. The user can search by: "Thing Name," and what I want returned to the user is values a, b, and c. I initially designed the database to have it all contained on a single sheet, and have column 1 be key_index, column 2 be name, column 3 be a, etc etc. When the user searches, the cursor will return the key_index, and then use that to pull values a b and c.
However, in my database "Thing alpha" can have a value a = 4 or a = 6. I do not want to repeat data in the database, i.e. have multiple rows with the same thing alpha, only separate "a" values. So what is the best way to organize the data given this situation? Do I keep all the "Thing Names" in a single sheet, and all the data separately. This is really a question of proper database design, which is definitely something foreign to me. Thanks for your help!
There's a thing called database normalization http://en.wikipedia.org/wiki/Database_normalization. You usually want to avoid redundancy and dependency in the DB entities using a corresponding design with surrogate keys and foreign keys and so on. Your "thing aplpha" looks like you want to have a many-to-many table like e.g. one or many songs belong/s to the same or different genres. You may want to create dictionary tables to hold your id,name pairs and have foreign keys referencing these tables. In your case it will be mostly a read-only DB so you might want to consider creating indexes with high FILLFACTOR percentage don't think sqlite allows it to do though. There're many ways to design the database. Everything depends on the purpose of DB. You can start with a design of your hardware like raids/file systems/db block sizes to match the F-System's block sizes in order to keep the I/O optimal and where to put your tablespaces/filegroups/indexes to balance the i/o load. The whole DB design theory/task is really a deep subject which is not to be underestimated nor is a matter of few sentences in the answer of stackoverflow. :)
without understanding your data better here is my guess at what you are looking for.
table: product
- _id
- name
table: attribute
- product_id
- a
I am creating a db for my android app which requires different tables for different types of users. Basically, if user type A logs in he will use Table A, user type B logs in he will use Table B and similarly Table C.
Should I go ahead and create 3 tables and use only the table which the user type has logged in? Would this have any significant memory implications (size of the db)? That is, if the table doesn't contain data, would the sqlite db still allocate some space (other than for definitions of the columns).
The other way would be to check the user type and dynamically create the table at runtime once user logs in. I prefer the first method if there isn't much space used.
Any pointers or suggestions would be very useful.
The SQLite DB will occupy some space to store the table structures and the constraints/indexes. Why don't u just create the database tables (w/o any data) using SQLite Browser and check the size of the database file.
Would help you decide.
I think instead of creating all tables at one go use SQL queries to create tables as and when needed. If its not needed anymore you can even drop the table.
In my application ,am work with a large database.Nearly 75000 records present in a table(totally 6 tables are there).i want to get a data from three different table at a time.i completed that.but the search process was slow.how can i optimise the searching process?
You might want to consider using the full-text search engine and issuing SELECT...MATCH queries instead. Note that you need to enable the FTS engine (it's disabled by default) and create virtual tables instead of regular tables. You can read more about it here.
Without being able to see the table structure (or query) the first thing I'd suggest is adding some indexes to the tables.
Lets say you have a few tables like:
Author
id
last_name
first_name
Subject
id
name
Book
id
title
author_id
subject_id
and you're wanting to get all the information about each of the books that an author with last_name="Smith" and first_name="John" wrote. Your query might look something like this:
SELECT * FROM Book b
LEFT JOIN Subject s
ON s.id=b.subject_id
LEFT JOIN Author a
ON a.id=b.author_id
WHERE a.last_name='Smith'
AND a.first_name='John';
There you'd want the last_name column in the Author table to have an index (and maybe first_name too).