I have a database like this:
Database example
My problem is I need multiple entries in the Substrate spot.
Kind of like a 3 dimensional database. I need to add in things like, hay, straw, potato peels etc. But it needs to be on the same spot like a list just for substrates. I cant go down the rows because that would be messing with the wrong mushroom and the only alternative I can think about is making substrate01, substrate02 substrate03 ... but since this can vary a lot, it makes no sense to make hundreds of rows just to reserve enough space for entries. One might only have 1 substrate and another might have 50 I need it to be dynamic.
Create another table, which contains a column for the key of the one row your trying to add to, and another column for the name, like substrate1, substrate2
So table one row might look like:
MushroomKey, mushroomname
Table two might look like:
Substratekey, mushroomkey, substratename
You might also want to learn about the normal forms of a database
If I'm understanding correctly, the general method to do this is to have a second table, linked by ID that contains one substrate. Then have one record per substrate in the second table.
If you need to display it all on one line, you can join the tables and use 'group concat' to assemble them.
Related
I've created a db in mySQL that stores many things, but specially images. The table name for storing the images is image, like so:
image (image_id, title, caption, filename, published_date, ...)
It's been almost 2 years and i've uploaded almost 5000 images into the table.
Now, i want to add a new functionality. I want to group similar images so when im looking at an image, i can also have the option to look at images that are similar.
I'm not sure if i need a new table or should i use the same table or both. Any ideas/suggestions on how it should be?
You should create another table with that similiarities.
Why can't it be the same table ? One record in You table can have many similiar records (so it will be adding many columns to that table or for every similiarity there will be another row in YOur table. So the only logical option is to create another table.
IdFromMainTable | IdOfSimiliarRecord
Later on You can show that similiarites in a view easily joining that table by IdFromMainTable. Or both IdOfSimiliarRecord and IdFromMainTable. [depends if u want to add 2 records for similiar records or just one for similiar pair]
It sounds like what you want to do is create tags for the images. There are a number of ways to do that, but adding the tags to the same table would prevent a whole lot of joins from taking place and would likely be faster. You could just store the tags as JSON (if you're using MySQL =>7.5.8).
What if I have it where I (in the design mode for my table, in a particular field) use the combo box to lookup the ID and the value and then make the value my bound column?
I understand I'm losing the ability to see relationships that I've made in this way on the relationships database tool. Am I losing anything else?
In other articles I've researched, they talk about queries not working correctly or the database being too rigid/hard to change after the fact. I don't necessarily see those problems.(although I'm still learning Access! =) )
When I build a Query to test if it returns the ID or the value, it returns the value, so what's the real problem here?
If I understand you correctly, you have a domain table that looks something like this:
DomainTable
-----------
DomainID
DomainValue
The rows of your table might look something like this:
1 Male
2 Female
3 Other
And you have another table where you want to include either the DomainID or the DomainValue.
Generally, you would use the DomainID. This allows you to make a change to the domain value without having to make the change in hundreds of places.
On the other hand, if you want changes to the domain values to not be reflected in your other tables, you would use the DomainValue. This is important when creating a log file, as one example.
My table looks like this,
RangeId CellId Some Coulmns more
101 1
101 2
I ll get a list with [101,2],[101,1] now i have to swap cellId values in the above table. How to write an update query for this. I went through Swapping column values in MySQL but this swaps between two coulmns. Any suggestion..
EDIT: I am swapping the cells in my app and i ll get two cell ids. I have two just swap 2 with 1 and 1 with 2 and rest of the values in the rows remains the same
EDIT2: The table doesnt have any Id column nor a primary key.
With your table as currently stated you cannot really do as you wish as there is no unique way to identify rows. I advise that you step back and look at what you are trying to do as it feels like either a: it's not been thought through, or b: you've not given enough information for this to really be solved
If b:, please provide more information on this table and the tables it links to and precisely what you are trying to achieve (yes I know you want to swap 2 numeric values however without knowing more information about the tables / what can be used to select it is VERY hard to advise accurately)
note below was written for OPs original edit
This isn't a nice way to do it but it may get what you are after, it relies on ID being a PKID
http://sqlfiddle.com/#!2/0c48c/2
I know this may be a simple question and if I knew what I was looking for in specific I might be able to find it on my own. However this idea is a little out of the box in my line of normal thinking. So the question is, can I store an object/array of data in a single column that is actually searchable without having to break the object/array down with server-side script.
What the concept is, is I have a table in my db currently and its not even a definite table currently. But what I was initially thinking of having is a single table that each row will have a unique id and with this id a set of numbers (or more if I can actually store an object). What this data is, is my hope for not have rows of what could be redundant data. This is part of a one-to-many / many-to-many concept. The only thing I can think of off the top of my head is Google+ and it's "Circles" I want to be able to take a set of things group them together in a Circle like thing. Where if I choose that circle it will only show to those I want it show to.
Maybe I have this all wrong. If so, if someone can point me in a more solid direction that would be awesome. Bottom line is, I have a series of tables that have one distinct ID across all of them that is unique. This table is hoped to bridge some of those IDs to other things I have in the works. Where I can group these IDs together with one distinct id.
You probably want to implement an ER diagram like this example:
A user can have zero, one or more circles.
Then there's a many-to-many relationship between users and circles.
Let's say I'm making a program for an English class. I'd like to store data in this way:
ID Object
0 Present Tense
1 1st person singular
2 To Be
3 I am
How can I retrieve the value for ID 3 based on IDs 0-2? The only thing I can think of is:
ID Object FromIDs
3 I am 0,1,2
The problem with this is that I'd have to do a fulltext index and I think this table is going to get pretty large. I don't want separate tables for different types of objects, if possible, because I don't know what I'll end up doing with these objects and I want as much flexibility as possible. I could have a second table relating IDs to each other, but I've only done that successfully relating a column from one table to a column to another.
Thanks in advance!
You need to break the data into different tables. Have a table that stores the "tense"
and another that stores the type "1st person singular".
Can you explain your problem a little more. From what you have I'm not sure if you're trying to go down the path of Entity-Attribute-Value or probably what is more likely is that relational database is not a good fit for your problem; you may need to use some sort of tree data structure. If you update, I can try to provide a better answer.
What I've decided to do is a combination of what was suggested and what I originally thought. I'm going to have a master list with IDs that are auto-incremented and copied to other tables. That way, I have properties of different parts of speech separated, but still have everything relating to everything else.
This is really not a good fit for a relational database. Sorry, you're trying to drive a nail using a screwdriver.
When you have no distinction between an attribute type and a value, you're modeling semantic data. The open standard for this type of data modeling is RDF.
My solution (if you really dont want to break up the table)
**ParentChildTable**
ParentID ChildID
0 3
1 3
2 3
But well, in one table now you have:
-type of tense
-type of person (1st, 3rd....)
-values
So i think it would be better to split, i can see .. .well, right now, 3 tables: values, tensetypes, personetypes and relationship table (value-value for tense/person)