I need to store multiple 4 letters strings for each database row but the amount of 4 letter strings could be different every time.
So would it be easier to setup a new table and add a new row for each 4 letter string with the id of the related row in the other table ?
For normalisation reasons and performance as well as being able to later perform efficient queries, you would want to store it in a related table.
Main : ID, other columns
Related : Main_ID, 4-letter-string
If there is nothing else you will store in the Main table, then just store them as multiple rows, and relate via a common ID.
You can store it on one record and still search efficiently, if FULLTEXT searching is turned on, but I doubt your 4-letter strings are natural language words, so it may not suit as well.
Related
I want to manage some datas by intervals on my database like that :
It is possible to do that on an unique table or I need 3 tables, one for each color (with FK) ?
Real example :
Actually, on my app I use this on a dataGridView and on my database :
It is possible to set / modify or everything on three databases. I manually add the equivalency (green) but for some number with a little different is it the same equivalency, so it's - for me - interesting to use numeric intervals
I'm not an expert on modeling databases but this is how I solve your scenario.
I'd create two Range Tables, one for storing column values, and other one for row values, each table will have same structure but since you need to represent the final values in a matrix way i decide to consider two tables(instead of merging them in one, its possible but then you'll need more effort to showing data from "Values"). As you can see i've considered a IdEquivalency columns, this will be useful for showing the data ad needed.
Finally the table Values(for green values) has two FK(one for each range value), and the value stored.
This is still a basic idea, but I'm sure you get the point.
Considerations:
Change Table Names according what its value represent.
task_set is a database with two colums(id, task):
id task
1 shout
2 bark
3 walk
4 run
assume there is another table with two colums(employee,task_order)
task_order is an ordered set of tasks, for example (2,4,3,1)
generally, the task_order is unchanged, but sometimes it may be inserted or deleted, e.g, (2,4,9,3,1) ,(2,4,1)
how to design such a database? I mean how to realize the ordered set?
If, and ONLY if you don't need to search inside the task_set column, or update one of it's values (i.e change 4,2,3 to 4,2,1), keeping that column as a delimited string might be an easy solution.
However, if you ever plan on searches or updates for specific values inside the task_set, then you better normalize that structure into a table that will hold employee id, task id, and task order.
I have a question about my DB design.
I want to save some information about province and the country. At the first I thought that I can save all of this information in one table (General_info). Then for each record in this table; values of columns, which belongs to country should be repeated.
Another idea is to separate this table into two tables (General_info_country and general_info_province). The first table with only 3 columns and the other with more than 10.
What should I do? Which approach is more efficient?
The biggest issue with the first approach (one big table) is that if any one country information changes, you need to update multiple rows, meaning you might make a mistake and end up with inconsistent information.
The second approach is normalized and considered a better relational design.
If the relation is one to one and will remain one to one, then you can go both ways.
But if it is one to many then of course you must split them, and have the foreign key in the many part
In the case where the relation is one to one the question becomes, how frequent are you going to use the all of the attributes ?
If you are going to use both tables together frequently then i suggest you do not split them because you are going to need to join them a lot in your queries.
But if you are going to be using the 2 tales alone rather then using the info from both tables together then splitting them could save you some time.
Currently I'd like to develop dictionary application for mobile device. The dictionary itself use offline file/database to translate the word. it just translates for two languages, for example english - spanish dictionary.
I've a simple design in my mind. it would be two tables: English Table and Spanish Table.
for each table contain of:
word_id = the id which would be a foreign key for other table
word = the word
word_description
correspond_trans_id = the id of other table which is the translation for this word to other language.
and also because of this is for mobile application, the database use SQLite.
The definition data for each table has been provided order by field 'word' on the table. However I'm still thinking the problem if there is addition for the data definition. Because the table would be order by field 'word', is there any method to put (insert) the new record still in order by word ? or any idea to make it more efficient ?
At least it for each translation there are a few translation possibilities depending on the context. if you like to do a bidirectional dictionary for two languages you need at least three tables:
ENGLISH
ID | WORD
1 | 'dictionary'
GERMAN
ID | WORD
1 | 'lexikon'
2 | 'wörterbuch'
TRANSLATION_EN_DE
ID_EN | ID_DE
1 | 1
1 | 2
The first two tables are containing all the words that are known in that language and the bidirectional mapping is done by the 3rd mapping table. this is a common n:n mapping case.
with two more tables you're always able to add a new language into you're dicitionary. If you're doing it with one table you'll have multiple definitions for a single word thus no normalized db.
you can also merge your language tables into a single table defining the words language by another column (referencing a language table). in that case you'll need a 2-column index for the language and the word itsself.
What do you intend to do when a word in language 1 can be translated by more than one word in language 2? I think you have to use something like wursT's design to handle that.
RE inserting records in alphabetical order: You do not normally worry about the physical ordering of records in a database. You use an ORDER BY clause to retrieve them in any desired order, and an index to make it efficient. There is nothing in the SQL standard to control physical ordering. Umm, I recall coming across something about forcing a physical ordering on some database I worked with, I think it was MySQL, but most will not give you any control of this. I haven't worked with SQLite so I can't say if it provides a way.
Surely the relationship between words and their possible translations is one-to-many or many-to-many. I'm not clear how you will represent this in your model. Seems like you may need at least one more table.
I agree with Matt - To make life much more easier I would stick with one table. Also if you plan to use CoreData, the index modelling of traditional database design is different to the object graph based model when working in Obj. C/IOS.
It's very easy to think along the traditional lines of Select querying and inner / outer joins but for example your column 'correspond_trans_id' would normally be handled by setting a 'relationship' when defining your data model for the two tables (if you are using CoreData of course).
In essence unless there is a good reason to have two tables I would stick with just one.
In relation to the ordering, you might not need to keep the order of words in the dataset. I'm guessing you want to keep everything Alphabetical which would involve some work if the data were to ever change, even for just one table.
Again using CoreData, NSFetchRequest and NSSortDescriptor, it is very easy to return a set of records ordered by a specified column, freeing you from having to worry about amends and additions to your database.
If you have any questions give me a shout.
For reasons that are beyond my control I need to store huge arrays (10000+ entries) in database rows, and it has to be easy to access each index of the array individually, which means I'd rather avoid serialization/blobs, if at all possible.
So my first idea, and the actual question here, is can I increase max columns for Oracle in anyway?
Or is there an easy way to say store the array over a few rows and hide the implementation below the surface (I'm thinking stored procedure here).
Any other suggestions are also welcome!
The maximum number of columns is a constraint of the database engine. So no luck there.
I don't know how many rows your database will contain, but it could be a solution to use a table that stores three fields: ArrayId, FieldIndex, Contents. Each array field is a single row in the database. If you put a combined index on ArrayId and FieldIndex, access should be pretty fast.
This solution would also allow for variable-length arrays.
Not sure about increasing the max columns.
However, Why not split it across multiple tables which each table sharing the same unique ID.
This implementation will be more easier than storing it over multiple rows.
Why not store the array as a Blob?
It is very unlikely that anyone would ever code "Where Acol999 = 42 or Acol1000 = 42 ..." in SQL so if you just want to store and retreive than store it as a Big Clob or Blob depending on your data.
This will be much quicker qnd involve much less code.
If you eally want to query the contents than you really need a separate table with 1 - ONE - row per array cell. You will then be able to query this sensibly.
CREATE TABLE ARRAY_CELLS (
PARENT_ID INT NOT NULL,
INDEXNUM INT NOT NULL,
VALUEOF LONG NOT NULL
PRIMARY KEY(PARENT_ID,INDEXNUM)
);
You can then run queries like:-
SELECT PARENT_ID from TABLE_ARRAY_CELLS WHERE VALUEOF = 42 GROUP BY PARENT_ID;
Which will give you a list of all the Arrays that contain value 42.