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.
Related
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 to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm a newbie.. not sure if this is the right place to post this, so please forgive me if it isn't.. i wanted to find out how or what would be the best approach when it comes to making a table for contacts in a database.. Here is what i have :
I have a table for users, this table contains user info like usernames and passwords,etc.. i want to make a program that will allow these users to add contacts,now i don't want to create a contacts table for each user,i would like to have a contacts table which contains all contacts and be able to reference them using an id .. Help please
You have a table of users and a table of contacts:
User - UserID, Username, Pw... etc.
Contacts - ContactID, name, phone, info...etc.
For a user to have multiple contacts and for multiple users to have the same contact, you need to create a bridge table to handle the many to many relationship. In this table you'll reference the primary keys (the UserID, and ContactID) from the tables above.
UserContacts - UserID, ContactID. (this can be a composite primary key)
You need to have a table with name of your choice..let's say Contacts
You can have this structure
ContactId (Primary Key)
ContactName
UserId
Etc..
You can start with above structure and improvise..
I recommend this article..
http://www.datanamic.com/support/lt-dez005-introduction-db-modeling.html
Table creation sample code:
CREATE TABLE contact(
contact_id VARCHAR(20),
contact_name VARCHAR(20),
user_id VARCHAR(20),
password VARCHAR(20)
);
data insertion sample code:
INSERT INTO contact(contact_id,contact_name,user_id,password)
VALUES("A123","Daniel","dan2015","password");
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.
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'
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am developing an application for a small financing company, where they can input payment amount. The date will be generated automatically. My question is, what is the best way to save those payments in MySQL, considering that some loans will be as short as 6 months, while others will be as long as 84 months?
I'm thinking about a table with 169 columns:
REC_ID as primary key,
Date1, Amt1, Date2, Amt2, etc...
But, how efficient would it be? On a 6-month loan, out of those 169 columns, only 13 would be used.
Thanks in advance for your output.
Create a payment table that has a the foreign key of the loan id in it.
the payment table will look something like this
id|loan_id|payment_date|payment_amount
Have a separate table for loans that will look like
id|loan_amount|loan_length
When you need to find out how many payments have been made run a query on the payment table with the loan_id as a search parameter.
This would be a gross violation of relational design paradigms, each payment and Date should probably be a its own tuple in a table with a many to one relation to the accounts table.
Accounts (REC_ID, other_stuff, other_stuff) Primary key(REC_ID);
Payments (REC_ID, timestampe, amt) Primary key (REC_ID, timestampe);
Also consider using foreign keys to enforce existence of a valid loan for each payment. And I would guess the policy would be cascade so that deletion of load and renames of loans would carry through to the Payments table.