I want to design a SQL table, where I can save all the damage marked in an image of a trailer, from the back, front, left, right, floor and ceiling, this has to be done when the trailer is leaving the base and when return to the base.
http://previews.123rf.com/images/dymentyd/dymentyd1511/dymentyd151100021/48099625-Front-back-top-and-side-semi-trailer-for-truck-projection-Flat-illustration-for-designing-icons-Stock-Vector.jpg
I think, I can divide every images in nine pieces, like this:
________________
|____|_____|_____|
|____|_____|_____|
o o I
and click on the corresponding spot with a damage, this could be one or more.
but with 6 sides and 9 pieces it would be 54 spots.
There are like 500 trips a day and more than 800 trailers, of course not all the trailers are going to have a damage on a trip, but when they come back to the base, we want to know if there is any new damage, so we need to compare the before and the after.
How it would be the best way of doing this? so I can do a select query and compare the data.
I think having 54 columns in a table for the same thing is not a good idea, maybe something like a column [damage] and insert the number(s) of the spot(S) 1 to 54.
_______________
|Trailer| Damage|
|-------|-------|
|t-3534 | 1,3,54|
|t-7523 | 23 |
|t-3562 | 11,12 |
Thanks in advance.
You are correct to avoid the column-per-damage-location design but your suggested alternative can be improved.
As a first step I would change from recording all individual pieces of damage to a trailer in the same record to storing each in it's own record. This would enable you to track the nature of each individual piece of damage and also to record multiple pieces of damage in the same location.
Trailer Location Description
t-3534 1 Minor scratch
t-3534 3 Minor dent
t-3534 54 Smashed tail-light
t-3534 54 Loose fender/bumper
Other enhancements that you might consider
Track when damage happened using a date/time column or reference to a trip table
Change description to a reference to another table with pre-defined damage types
location could be more "granular" e.g. split into two parts "side" and "position"
All of these are of course dependent on other requrements that you may have
Related
I'd like to do some Php graphs with MySQL datas, but first I have to think about the best design for my database, I prefer ask you some advice because I'm a newbie and I think there is a better way that the one I'm thinking.
I have a main table called "companies", with an autoincrement id column and a region column, more companies and more column could be added later.
On the Php graphs, I'd like to choose the graphs by companies regions and maybe others filters later, this is why my table "companies" is the the central table.
I'd like to fetch new datas (stocks, commands, roi, etc..) for every companies one time per day and use those datas on graph. The old datas won't be overwritten but keep for the graphs history, more data I'll have more the graph will show the behavior of the company.
So, every day there will be one more row per companie (more than 200 companies in total), and this point is my issue.
I was thinking to create one table per companie and add a new row everyday on each on those tables, but I feel it's dirty and there is a better and cleaner way to do that, is anybody can show me the best way ?
Thanks for reading, I hope you'll can help me.
From what I understand, you have at least those entities in your domain:
Companies
Company indicators (stock, ROI, commands, ...)
Indicator types (stock, ROI, commands, ...)
Regions
So you should probably have something similar to the schema below:
,---------.
,-------. |Indicator|
|Company| |---------|
|-------| |date |
|name |*---|value |
|-------| |---------|
`-------' `---------'
o o
| |
,------. ,-------------.
|Region| |IndicatorType|
|------| |-------------|
|name | |-------------|
|------| `-------------'
`------'
I'm creating a MySQL database with tables that contain information about different types of products.
As an example, let's say Table1 contains bicycles and Table2 contains t-shirts.
I want to be able to store information about things like which colors each of the items in each table are.
For example, there might be a bicycle in Table1 that's blue and yellow, and a t-shirt in Table2 that's red, green, and orange.
Originally I had intended to store color information as binary numbers in each table and use bit masking to figure out the colors of a particular object (i.e. 1 = red, 2 = blue, 4 = green, 8 = orange - if the value is 5, the object is Red and Green). I was going to have a foreign key table with the values for all the single colors (i.e. Red = 1, Green = 4) and use sums of the values from that table as bit masks.
I assumed doing it this way would be "faster", but I've been "Googling" this subject for weeks before making a decision and found out that it's "faster" to have a foreign key table so indexes can be used. (i.e., if you wanted to see if a t-shirt with the color value set to 13 included the colors Red and Green, rather than doing "13 & 5" , you would check row 13 in the foreign key table to see if the values for Red and Green were set to 1.)
The thing is, the list of colors I'm using is currently at 26, and I'm anticipating that it will grow. (I was trying not to go over 31 colors so I could use an INT column to store the values, where 0 = "none".) If I were to make a foreign key table to cover all possible combinations of 31 colors, it would have to have 2,147,483,647 rows and 32 columns (one true/false column for each possible color). Every time another color was added, I would have to double the number of rows in the table (like, one additional color would require 2147483648 more rows).
I assume it would be preferable to make a "junction table" like this:
+----------+------------+
| shirt_id | color_id |
+----------+------------+
| 1 | 1 (Red) |
| 1 | 4 (Green) |
| 1 | 8 (Orange) |
| 2 | 2 (Blue) |
| 2 | 4 (Green) |
+----------+------------+
Then there wouldn't need to be a gigantic table listing every possible combination (the vast majority of which might never be used). The thing is, there would have to be junction table for every product type, and there are going to be a large number of product types, meaning a large number of junction tables.
I'm using colors as an example, but I had actually planned to do this for several other "stackable" values as well (for example, a single object could be composed of hardwood and aluminum and glass and particle board and ABS plastic and PVC and cardboard...and so on, all at the same time).
My question is, what is the most efficient method of handling situations like this? Is there a method I haven't thought of that's preferred over these?
I'm only using colors as an example - the database will actually have a number of "stackable" attributes like this (things like material, fiber type, texture, finish, etc.) that can apply to more than one product type, and the "products" themselves will be "generic" and have have a "stackable" value that indicates the types of components that make them up (like, a "product" that includes a bicycle and a t-shirt packaged together).
Having written this, I imagine using multiple junction tables would be the most efficient way to do it. But as an "old-school programmer", it's difficult for me to get my head around the idea that making [for example] 30 different junction tables just for product component/color combinations alone could possibly be "preferable" to just directly analyzing bits in a binary value. (I do realize MySQL is not a Nintendo Entertaiment System...)
I've once implemented bit-masking on a field for different domains. However this was clearly a case that was going to provide a big performance improvement as it would avoid having to join 8~10 tables. Bit-masking is extremely fast, especially if the field is indexed.
With the index for a 32-bit field then it will at maximum do 31 comparisons to find the resulting rows.
Without the index it would still have to perform the bit-compare on every row.
However there is a big 'if'. It's not easy to maintain and the shirt colors will always be limited to the bit-length and in the case that you describe I would really opt for the junction table and just make sure to have the index on your foreign keys.
The question of performance depends on the queries being used, as well as the structure of the data. Your question doesn't include information on the queries.
But, there seems little reason not to use a junction table. This would involve a table called Colors with an auto-incremented primary ColorId. Then for each table that required colors, you would have a table, such as BikeColors with one row per bike and color.
I wouldn't attempt to do this using bit-fiddling, unless you have a really good reason to. That is, unless you have tried a junction table, and for some reason that doesn't meet your needs. A junction table can take advantage of indexes. Bit fiddling generally does not.
Also, I would question why you have separate tables for bikes and T-shirts, unless you have a lot of columns that differ between them. For most retailing purposes, one table would be sufficient for multiple products.
I'm creating a DB for my office. We have about 200 employees. Each employee was required to complete at least 1 of 12 courses within 2 years of being hired (so different completion/qualification dates for every course, some people have been here 20 years, some just 1 year) to become qualified. Some have completed multiple courses. Each course has to be refreshed periodically (each refresh period is different and based on the last refresher date). I'm having trouble with the layout of the table. Here's what I have as an idea, but i'm trying to see if there is a less busy way to lay out the data. I want to be able to run a query that tells me what person has completed what class (so it would have to look at all 3 class columns). I also want to be able to tell when their qualification has lapsed, or is coming up. So far I've created an employee data table that looks like the table below.
ID Name Class1 Class2 Class3 QualDt-Cl1 QualDt-Cl2 QualDt-Cl3 LstRequal1 ...
1 Bob Art Spanish 3/17/1989 9/12/2010 3/8/2012
2 Sally Math 8/31/2012
3 George Physics History 2/6/2005 7/6/1996
4 Casey History 6/8/2000
5 Joe English Sports Physics 12/10/1993 10/15/2001 4/22/2006
The classes are listed in their own table and each class column pulls from that. The qual date refresher will be a calculated column in the query based on the last refresher date.
Is there a way to put all the classes one person is qualified for in one column and have the associated date for requalifiing for each particular cours in another column?
I think it would be less confusing if you had a table per subject and register the people's names under each one with the date passed.
Also it would probably help to declutter the table from uneccssary info like the exact date the exam was passed, you can do month and year or maybe just year? if the lee way is 2 years that would probably make more sense - also making the qulified calculation easier.
The query would work if you searched per subject maybe ? or who would qualify to do what subject this current year and then the next.
this is not much of a question that you would ask on here by the way - but hope the answer helps.
When designing a database, any time you find yourself adding columns with names like Class1, Class2, Class3 you should immediately stop and think about whether it makes more sense to put those columns in a separate child table called Classes with a link (relation) to the parent. There are several reasons for this, including:
What happens when somebody takes a fourth course? Saying "that will never happen" ignores the fact that "never is a very long time" and none of us can predict the future.
When checking whether or not someone has taken a course you really need to check (Class1 IS NULL) OR (Class2 IS NULL) OR (Class3 IS NULL) and that can get really tedious, It also means that if you do have to add Class4 then all of that SQL code has to be corrected.
Similarly, if you want to find someone who took "CPR" you'd have to look for people with (Class1 = 'CPR') OR (Class2 = 'CPR') OR (Class3 = 'CPR'). Yuck.
So, save yourself some trouble (a lot of trouble, really) and create a Classes table:
ID
ClassName
QualDate
(etc. )
...where ID is the ID number from the main table (what is called a "foreign key"). From your sample data, your Classes table would look something like this:
ID ClassName QualDate
1 Art 3/17/1989
1 Spanish 9/12/2010
2 Math 8/31/2012
3 Physics 2/6/2005
3 History 7/6/1996
...
I'm new to (My)SQL and it's been difficult to find good info on best practices of table design.
I want to save sequences of moves on a chess board, say I have an array $a = ['e4 e5', 'Nf3 Nc6', ...]
Being new, my first idea is a dumb little table with 2 columns, one for the Game ID and one for the moves. The moves (array) would be serialized and stored in a string. I guess this would technically work, but reading and writing potentially huge serialized arrays from a DB - perhaps on every page load - seems suboptimal to me.
Caching the array on the user side might not be possible for various reasons and is not something I'm curious about.
I'm interested in learning how to best store data that can't be entirely predicted in it's format (e.g. the number of moves can vary from 1 to 1000).
Rather than storing the entire game history in a single row, why not store the game ID, the move, and the sequence number of that move.
That way you would retrieve the entire history of a given game by doing something like
SELECT *
FROM MovesTable
WHERE gameID = id
ORDER BY sequence
In general, I would use a table in one of the following forms:
GameId, MoveNumber, Move
GameId, MoveNumber, FromSquare, ToSquare
Which one you use will depend on what you will need to query against and how the data will be presented, but I would lean toward the latter suggestion.
You can then combine this with a parent table that contains the GameId and some data about the game itself, such as dates or players.
If you're only going to consume the moves as an entire block - that is you always want the entire move chain and never will query into individual moves - you could store the string as you suggest. This has the added benefit that there is only one row of data to return, which will be very fast. The downside of course is that you will have to deserialize/parse the data once you receive it.
I'd do something like
Game, MoveNumber, Move
----------------------
Game1, 1, e4 e5
Game1, 2, Nf3 Nc6
...
Game2, 1, ....
You will need a number of tables, one for the players, one for games, one for the pieces and one for moves.
A game would have players and colours and things like date and time
A piece would tell you how it moves, is it a knight or a queen etc.
A player would have the player's name etc.
A move would have the piece, game, player, start position and end position
You would link these tables together by relationships based on id fields in each of the tables.
Try two tables.
First table contains information pertaining to each game. Who are the players, where and when did they play, who won, and whatever other information is pertinent to each game and makes each game unique.
Games
Game_id PK
Move_id FK
Black_name
White_name
Game_Location
Game_Date
Game_Time
Winner
The second table contains all the moves for each game. This contains all the pertinent information for each move: was a piece taken, was the other player put in check, was this a regular move or did they castle, etc.
Moves
Move_id PK
Move_number
Who_moved
Piece_moved
Square_from
Square_to
Piece_taken
Move_type
Check_YorN
Now each row in the Games table (game) is joined to many rows (moves) in the Moves table.
This is my first project outside of school so I'm rusty and lacking practice.
I want to create a database but I'm not sure if I'm doing ok so far. I need a little help with the reports table.
The situation:
The food bank has multiple agencies who hand out food
Each agency has to submit a report with how many families/people served from a long list of zip codes.
I thought of putting a fk on Report to Zips table. But will that make selecting multiple zips impossible?
Maybe I'm way off base. Does someone have a suggestion for me?
A better name for this table might be FoodService or something. I imagine the kind of reports you really want to end up are not just a single row in this table, so naming it Report is a bit confusing.
In any case, each Report is the unique combination of {Agency ID, ZIP code, Date} and of course Agency ID is a foreign key. The other columns in this table would be number of families and people served, as you've indicated. This means you'll have rows for each agency-ZIP-date combination like this:
Agency | ZIP | Date | FamiliesServed | PeopleServed
Agency A | 12345 | Jan-12 | 100 | 245
Agency A | 12340 | Jan-12 | 20 | 31
Agency B | 12345 | Jan-12 | 80 | 178
Agency B | 12340 | Jan-12 | 0 | 0
Are these totals also broken down by "program"? If so, program needs to be part of the primary key for this table. Otherwise, program doesn't belong here.
Finally, unless you're going to start storing data about the ZIP codes themselves, you don't need a table for ZIP codes.
Usually having orphan tables like "Food" is a sign something's missing. If there's that much data involved, you'd think it would link in to the order model in some capacity, or at the very least you'd have some kind of indication as to which agency stocks which kind of food.
What's curiously absent is how data like "families-served" is computed from this schema. There doesn't seem to be a source for this information, not even a "family served" record, or a spot for daily or weekly summaries to be put in and totalled.
A "Zips" table is only relevant if there is additional data that might be linked in by zip code. If you have a lat/long database or demographic data this would make sense. Having an actual foreign key is somewhat heavy handed, though. What if you don't know the zip? What if, for whatever reason, the zip is outside of the USA? How will you handle five and nine digit zip codes?
Since zips are not created by the user, the zips table is mostly auxiliary information that may or may not be referenced. This is a good candidate for an isolated "reference" table.
Remember that the structure of a diagram like this is largely influenced by the front-end of the application. If users are adding orders for food items, that translates into relationships between all three things. If agencies are producing reports based on daily activity logs, then once again you need relationships between those three entities.
The front end is usually based on use-cases, so be sure you're accommodating all of those that are relevant.