Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I have a table with 4 columns:
id1 int
id2 text or varChar
type
timestamp
The primary key is (id1,id2,type)
and I want to change to (id2,id1,type) .
What is the difference in performance will be?Maybe it will be similar to the keys on the performance?
Don't add such kind primary key, use a long/int value for primary key, or a sequence if your database has one.
And, if you want to make a column or a combination of columns to be unique, just mark it or the combination of them as unique.
And also, for columns which are not primary key, you can also add index key to it or them, if need to.
You'll have two indexes like:
id1, id2, type - together(so you must use all three column in WHERE clause).
Also
1 case(id1,id2,type) - you can use in WHERE separate id1.
2 case(id2,id1,type) - you can use in WHERE separate id2.
But it's not really good practice to use several column as primary key.
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I created a table called 'parent'
Create table parent (p_id int(11) primary key, p_name varchar(255));
And another table called "child" with foreign key referenced to the parent Id table as below
Create table child (ch_id int(11), primary key, ch_name varchar(255), ch_fk int(11) references parent(p_id));
Both tables were created successfully and I add some data in both of them. But when I tried to get the data of a parent and his children it renders all available data of the child table
My query is as below.
Select * from parent , child where p_id=2
You want to join the tables explicitly - otherwise you end up with a cartesian product, where all rows on one side are joined to all rows on the other side.
I suspect what you want is:
SELECT * FROM parent p INNER JOIN child c ON p.p_id = c_ch_fk WHERE p_id=2
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
When creating a new index it seems that people try to avoid holes inside it, and usually use auto-incrementation. But why? What the reasons behind that? Maintenance? Security? Or simply not beautifull?
Because in my case, I'm suppose to create a book catalog database and for consistency reasons I would like to make sure that the index of the "book" table matches the fragment of the ISBN number corresponding to the publication number of the 1st edition of the book at this publisher.
However some reissues have their own ISBN but won't be counted as a book entity in itself and so will create holes (data of reissues will be merged with 1st edition data).
I use MySQL 5.7.23 with phpMyAdmin.
Here the view from the junction of the tables "Book" and "ISBN" I aim
num_book | ISBN
--------------------------------
1 | XXX-X-XXXXXX-1-X
| XXX-X-XXXXXX-5-X
| XXX-X-XXXXXX-9-X
| XXX-X-XXXXXX-14-X
2 | XXX-X-XXXXXX-2-X
3 | XXX-X-XXXXXX-3-X
| XXX-X-XXXXXX-6-X
| XXX-X-XXXXXX-8-X
4 | XXX-X-XXXXXX-4-X
7 | XXX-X-XXXXXX-7-X
| XXX-X-XXXXXX-13-X
10 | XXX-X-XXXXXX-10-X
11 | XXX-X-XXXXXX-11-X
12 | XXX-X-XXXXXX-12-X
15 | XXX-X-XXXXXX-15-X
I intend to use "num_block" with these intentional holes as primary key of the table book and then join with ISBN table.
The index numbers will remain increasing but wouldn't necessarily be successive (i.e. 1, 2, 3, 4, 7, 10, 11, 12, 15)
Should I worry about that and why ?
Thanks by advance for your attention.
Edit : Oups as scaisEdge said, forgot can't start index with 0, corrected.
More clarifications & disambiguations about explanations and the sketch (add legend) : it's not the same table a but a view from the join of two tables (books and ISBN), so "num_book" value are unique but can be bind to severals "ISBN".
I think you are referring to a few different concepts all at the same time.
There is a difference between a primary key and an index.
A primary key is a logical concept - it provides the unique, unchanging reference to a row in your table. As other entities refer to the primary key, it may not be null.
An index is a physical concept - it's a way for the database to look up entries in that column. You can specify that an index is not null, and unique.
The usual way to physically implement the logical concept of primary key is through a unique, not-null index.
The next question is how to assign the primary key; there are two candidates: natural keys reflect an entity in the problem domain, and surrogate keys are assigned automagically by the database.
In practice, there are very few natural keys (guaranteed unique, not null, unchanging) - I don't know enough about how ISBNs are assigned to have an opinion whether they are suitable. But I've seen problems with social security numbers (they get entered incorrectly into the system), phone numbers (people change their phone number), etc.
Surrogate keys are assigned by the database engine. They are often auto-incrementing integers, but they can also be UUIDs - as long as they are guaranteed unique and not null. The reason auto-incrementing integers are popular is for a couple of reasons.
Many primary keys are implemented using clustered indexes. A clustered index affects the order in which data is stored on disk, so if you have a clustered index, inserting record with ID 1 after you've written record with ID 1000 means re-ordering the data on disk, which is expensive.
Gaps are not really a problem - as long as you're inserting sequentially.
However...this logic is from the 1980s. Back then, a clustered index was notably faster than a non-clustered index. On modern hardware, that's not true in most circumstances.
So, there is no obvious reason why your scheme for assigning primary keys would be a problem as long as you are confident about the way ISBNs are assigned.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I’m currently trying to design my table structures for a made up database. The database will have three separate tables and track the populations of cities for 10 years. After every year, population figures will be added for each city in the database. Here is how I’ve laid out my three tables so far:
Cities (city_id, city_name, city_abbrv)
Year (year_id, year)
Stats (year_id, city_id, population)
I’m worried about not having a unique identifier in my Stats table. With 10 cities, the year data will be the same for 10 entries. Once I enter multiple years of data, the city_id will be reused. In my research on this site I’ve read that having a unique ID for every table is not required but the book I’m using to learn database design (while brief) never mentions that this is okay. I would like to know the best way to design a database that receivers data entries for the same group of things on a daily/weekly/monthly/yearly schedule. Should I add in a unique_id column to my Stats table? Or would this be a wasted column? Thanks for the help!
First of all you need each of those tables to have the column id as primary key.
A primary key is used to uniquely identify a table row. A primary key cannot be NULL since NULL is not a value. So basically those columns will be unique yes.
Question: Why you need primary keys in your tables?
Answer:
If you are looking to select data from different tables you are opting for join so you need keys to use for that join.
If you want your
table to be clustered, you need some kind of a primary key.
Side Note: You may need to get familiar with indexing columns, see advantages of indexing.
Cities (id, city_name, city_abbrv) //with id as primary key
Year (id, year) //with id as primary key
Stats (id, year_id, city_id, population) //with id as primary key
//And year_id and city_id as foregin key connected by their respective ids
If you are still beginner with MYSQL see the W3school tutorial for SQL primary keys.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
We store records with the following structure:
Ssn, lname, fname
in a data file ordered on lname
If we want an index on lname because lots of queries search based on
last name, what kind of index is needed?
From what i can get from your requirements, Try adding B-tree index to that particular column .
For people names, I recommend the composite INDEX(lname, fname). This will help (to some extent) each of these:
WHERE lname = 'James'
WHERE lname = 'James' AND fname LIKE 'R%'
WHERE lname = 'James' AND fname = 'Rick'
Your clustered PRIMARY KEY is probably SSN; this index may as well be a secondary (non-clustered) index.
In MySQL, BTree is essentially the only choice. Anyway, BTree is at least nearly as good as Hash.
Caution! Storing SSNs is a serious security problem. If you lose your machine, or it is hacked into, you will be in deed dodo. Meanwhile, don't plan on me giving you my SSN.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Improve this question
I am making a table of a products like different types of vehicles: cars, trucks etc. They are made by an array of countries and each country has an array of makers, like Japan has Toyota, Honda, etc and US has Ford, GM etc. Once the database is built, I need to do operations like "select all vehicles made by Toyota".
What is the best way to store that?
The data structure is not necessarily the same as your array structure. The key word is "normalisation": design your tables in a way that avoids redundancies and make sure that each record in a table contains exactly the information that is relevant to describe the subject of that particular table.
A possible structure could be:
create table vehicles(
vid int auto_increment primary key,
void int,
vname nvarchar(32),
vtype int,
vmotor varchar(32), ...)
create table oem (
oid int auto_increment primary key,
oname nvarchar(32),
countryid int, ... )
The column void of table vehicles references the primary key oid of the oem (original equipment manufacturers) table.
A typical query can be the following:
select * from vehicles where
exists (select 1 from oem where oid=void and countryid=7)
countryid is just an integer key referencing yet another table (not listed here) containing country names etc.. Assuming that record 7 of the country table contains 'Japan' then the above query will list all vehicles made in Japan.
Or - coming back to your original example -
select * from vehicles where
exists (select 1 from oem where oid=void and oname='Toyota')
would list all vehicles of that particular manufacturer.
This little example is just the starting point for you to understand `normalisation'. Like Marc B already said: Study the concept for yourself and you will be able to answer your question yourself. Here is another example based link that might be helpful: http://db.grussell.org/section008.html .
Why not just have a table called Automobiles,
and then rows like Car, Model, Company,Country
and then you can just
SELECT * FROM Automobiles WHERE Company = 'Toyota' AND Country = 'Japan'