I am unsure how to ask this, but I will give it my best shot. Currently, I have a few tables which hold indices into other tables to get information. For example, I have a row with name_id as 1, which indicates that I should look at the 'name' table and go to index 1. Is there anyway to directly link a row within a row? Is there another design choice which would be much better than this? Thanks!
You want to use what are called foreign keys, here is an explanation of them in Sqlite.
this is the preferred method of database design
you write a sql statement that uses a JOIN to get the linked rows back.
Related
i'm wondering if there is a way to relate between rows in the same table.
for example: i want to store a keywords in the database and make every single keyword points to others which are related to it. (instead of creating a table to every single keyword and add related keywords to it)
if not, hope anyone can suggest an idea to store keyword and relate between them with minimum size.
Thanks,
I need to store status of an entity, but i'm stuck with question of what is the better sql type. I'm using postgresql and see following possibilities:
Varchar
Enum
Separate reference table
Enum is not bad even if i will add new statuses and now it seems to be more simple and clear then reference table. Is it right?
And another question is what is better option for performance in select queries? Enum is similar to int, but reference table turn to query with join or where exists query to filter by status.
Help me to understand what is better?
If the status might be in more than one table, then I would recommend a reference table. This ensures that the statuses are consistent.
Within a single table, you could use a varchar() column with a check constraint. However, I would probably still lean toward a reference table.
A reference table has another advantage beyond consistency. It makes it easier to store information about the status -- for instance, short names, long descriptions, "default" values for certain attributes, and so on.
I am building a community site where logon will be by email and members will be able to change their name/nick name.
Do you think I should keep member name/nick name in my members table with other properties of member or create another table, write member name/nick name on that table and associate member’s id.
I am in favour of second option because, I think it would be faster to pull members name from it.
Is it right/better way?
Update: reason is for other table is that I need to pull username for different sections. For example forums. Wouldn't it be faster to query a small table for each username for each post in a from topic?
I would keep it one table and set a unique constraint on Email in that table.
I can't see a single advantage in adding another table.
Why do you think the second option would be faster?
If nickname is a required one-to-one relation to member ID the appropriate place to store them is in the same table. This is still a indexed single-record search so it should be more-or-less as fast as your other option.
In fact, this solution would probably be faster, since you could get the nickname in the same SELECT as you get the other information.
Update to answer the update to the question:
The second table isn't any smaller in terms of the number of rows. The main factors in a SQL search are 1) number of records in the table and 2) number of possible matches from the indexed part of the search.
In this case, the number of records in your smaller table would be exactly the same as the larger table. And the number of possible matching records returned by the index will always be 1 because the member ID is unique.
The number of columns in the table you're searching is generally irrelevant to the time taken to return the data (the number of column you actually list in the SELECT statement can have an effect, but that's the same no matter which table you're searching).
SQL databases are very, very good at finding data. Structure your data correctly and let the database worry about getting it back to. Premature optimization is, as they say, the root of all evil.
Go with the first option: keep the name/nick name in the members table. There's no need to introduce an additional table, and the overhead of a join that goes with it, in this case.
Yes, associating member's ID to the other properties is the right way to go.
You can simply create an index on name to speed up your queries.
Relationship tables mostly contain two columns: IDTABLE1, and IDTABLE2.
Only thing that seems to change between relationship tables is the names of those two columns, and table name.
Would it be better if we create one table Relationships and in this table we place 3 columns:
TABLE_NAME, IDTABLE1, IDTABLE2, and then use this table for all relationships?
Is this a good/acceptable solution in web/desktop application development? What would be downside of this?
Note:
Thank you all for feedback. I appreciate it.
But, I think you are taking it a bit too far... Every solution works until one point.
As data storage simple text file is good till certain point, than excel is better, than MS Access, than SQL Server, than...
To be honest, I haven't seen any argument that states why this solution is bad for small projects (with DB size of few GB).
It would be a monster of a table; it would also be cumbersome. Performance-wise, such a table would not be a great idea. Also, foreign keys are impossible to add to such a table. I really can't see a lot of advantages to such a solution.
Bad idea.
How would you enforce the foreign keys if IDTABLE1 could contain ids from any table at all?
To achieve acceptable performance on joins without a load of unnecessary IO to bring in completely unrelated rows you would need a composite index with leading column TABLE_NAME that basically ends up partitioning the table into sections anyway.
Obviously even with this pseudo partitioning going on you would still be wasting a lot of space in the table/indexes just repeating the table name for each row.
Isn't it a big IF that you're only going to store the 2 ID fields? If I have a StudentCourse (or better yet Enrollment) table that has StudentID & CourseID, but wouldn't EnrollmentDate go in this table as well since not all students enroll on the first day of class. Seems like a bad idea to add this column to an already bloated table where most records will be null.
The benefit of a single table could be a requirement that the application has the ability to allow user/admin to create these relationships with data (Similar to have a single lookup or reference list table) and avoid having to create a new table to address these User Created References. Needing dynamic querying may benefit as well. An application that requires such dynamic data structure requirements might be better suited for a schemaless or nosql database.
Is there a way to map one of the the columns contents of a MySQL table to an enum on another table in MySQL? I thought this would be a no brainer, but there doesn't seem to be any info that I can find on the subject.
Any advice or help on this matter would be cool and if it's not possible, does anyone know of an internal reason why it wouldn't be possible?
Best regards everyone :)
Gary
The enum type is handy as a one-off, but it doesn't scale well to multiple tables and isn't standard SQL either.
Best thing to do here is to use normal tables and relations:
Define a new table to hold the list of possible values; let's call it Master1
In the other two tables (let's call them Table1 and Table2), don't make the field an enum; just make it a normal field with a foreign key relation to Master1.
The foreign key relation will do the job of restricting to a list of possible values; and because foreign keys and relations are absolutely standard SQL, this approach will have other benefits - for example reporting tools can recognise the foreign key and understand how to use the related data.
If it doesn't do it, don't do it
Surely you just want a table of possible keys and then a foreign key mapping to that.
If you want a table with possible enum values and restrictions, go for groupings via another table or a groupid in the same table (if group members are unique).
Smells like table-stink though JOIN wise. Maybe best doing this in a stored procedure or in the app code and mapping it to a native value?