A basic question.
Think of football/soccer.
I thought about making a design pattern for it, but wanted to know if there is already one out there.
It goes as follwing:
I want to create a football player.
We have a gender. (Male and Female).
A gender have a Series Category (for example for young under 19, for young under 18 etc.).
That Series Category is placed in a region (or state whatever).
And that Region has its series' name (for example series 1, series 2, division 1 etc.).
For example, I want to make female, Senior, she plays in Birmingham, and is in the first division.
I want to map this into the database, but I wanted to follow a software design pattern, but I do not know if there is a software design pattern for this purpose.
My attempt is like this:
Gender
{
int GenderID
GenderType
}
SeriesCategory
{
int SeriesCategoryID
string SeriesCategoryName
int GenderID
}
Region
{
int RegionID
string RegionName
int SeriesCategoryID
}
Series
{
int SeriesID
string SeriesName
int RegionID
int SeriesCategoryID
}
I think you should design your database using normalization principles (read more here - http://www.studytonight.com/dbms/database-normalization.php )
Regarding software patterns - the are no exact patterns for your case. But use best practices and principles like SOLID. Mapping code entities to database ones and vise versa is responsibility of ORMs, which are existing in huge number of variations for different languages and requirements (SQL/NOSQL, code-first/database-first etc).
So for your exact case with footballers and teams I think DB normalization is all you required at the moment.
Why do you need all the attributes of "Series" separately. If that is not a necessity I would have created just a "Footballer" and a "League" objects. And probably one footballer can play in one league, but there can be many footballers in a league. Therefore there would be a many-to-one relation between "Footballer" and "League.
Footballer
{
int FootballerID
int age
GenderType
League
}
League
{
int LeagueID
String leagueName
String regionName
String categoryName
GenderType
}
So there is a many-to-one relation between FootballerID and LeagueID. First you can create a league without any footballers in it.Then, you can create a footballer with its age and gender, and then you can add this footballer to a league by checking their age and gender restrictions in the league category. A team object could also be nice though.
Related
My Goal: To find out which University has the larger amount of user (DISTINCT and COUNT in MySQLi).
I've been developing a survey website for Portugal, England and France.
In the survey some questions answer has predefined answer options.
For example: Gender, Living Country, Graduation Level (undergraduate, graduate, PhD, BBA etc)
But I also have questions where users need to write down the answers.
For example, University Name (where the user studied).
Two users filled the form as follow:
In this case the text "University of Glasgow" in English and the text "Universidade of Glasgow" in Portuguese is difference but it's the same institute.
So, these two institute has one user but the truth is this (as both are originally same University) University has two users.
My Question: How can I get the expected result?
I was planning to use Google translate but I it won't be accurate.
I also thought about to have all the University name in 3 languages but there are more than thousands of University, so it may not be efficient.
The structre I thought for table is,
survey_table
id, que_en, que_fr, que_pt, university_name
statistics_table
id, university_name, count
You could use localization for the university name. Check the docs here:
https://laravel.com/docs/5.7/localization
Make your users choose from a drop down list based on their locale (language)
I try to build a database model for the following structure:
I have companies with up to 3 hierachical levels. For each unit I have a value (these values are given randomly and duplicates between companies (not within) are possible. Let us say (1 Level: 222-Amazon, 2 Level: 441-Amazon: Germany, 542-Britan, 3 Level: 6-Distribution, 99-Shop, 124-Programming, 5-HR.
Of course for each company this is different. What I did is:
Table1:
ID_Worker
CompanyName
ID_CompanyLvL1
ID_CompanyLvL2
ID_CompanyLvL3
...
Table2:
ID_CompanyLevel1
Slot1
Slot2
...
Table3:
ID_CompanyLevel2
Slot1
Slot2
...
But with this approach I have the following problem: If two companies have the same number for a CompanyLevel1(2 or 3) unit I cannot distingush them anymore.
Another approach that is not working is
Table1:
ID_Company
ID_Worker
ID_CompanyLevel1
...
Tabel2:
ID_CompanyLevel1
Slot1
ID_CompanyLevel2
...
Table3:
ID_CompanyLevel2
Slot
ID_CompanyLevel3
...
With this approach I cannot identify which person is in e.g. which level2 unit. Could anyone help me with this i just cannot come up with the right design.
You need to decide whether the organization structure is purely hierarchical (an org unit can only belong to 0 or 1 other org unit), or whether it is graphical (an org unit can belong to 0, 1, or 1+ org units).
Your limit of three is a business rule, and should be enforced by database logic (trigger) and not the database schema.
Why the codes with the names?
If hierarchical, this is your schema:
create table organizations (
organization_id int primary key,
name varchar(whatever) not null,
parent_id int null references organizations(organization_id)
);
Use Recursive Common Table Expressions to query them.
If graphical, this is your schema:
create table organizations (
organization_id int primary key,
name varchar(whatever) not null
);
create table organizations_structure (
parent_organization_id int references organizations(organization_id),
child_organization_id int references organizations(organization_id),
primary key (parent_organization_id, child_organization_id),
check (parent_organization_id <> child_organization_id)
);
For anything like that - make sure you do not put yourself into a cornder. For example:
I have companies with up to 3 hierachical levels
No. YOu do have companies with CURRENTLY up to 3 hierarchical levels. And they do not want to scream at you when one of them decides to have 4.
I would suggest reading the Data Model Ressource Book Volume 1 - they describe all kinds of stuff and standard data schemata, among them entity organizations (entity as in "legal, human or organizatonal entity" which includes organigrams. Things are a lot more complex as you think when you do not want to put yourself into a corner that WILL make the program require a rewrite in the not too far future.
I have just started a new database project to price customer bid proposals:
Some of the tables in the database will contain information that is regularly updated say for example the pricing tables.
Now new bids should always use the latest information on the database, however existing bids should continue with the data used when they started unless the bid author decides otherwise.
Matters are somewhat simplified as a bid will under no circumstances use prices across versions so even if a product was coasted and available on an older version of the pricing table, it will not be available to newer projects.
In order to achieve this I am planning to include a version column and perhaps a linked version control table. I think this will be enough.
However I feel like this must be a common database design requirement and thus there must be existing “best practices” and techniques to achieve this so I’d rather build on existing experience than poorly reinvent the wheel.
Any advice on how to resolve this problem? Also I am working with the Grails platform so any Grails specific information would be much appreciated.
I'm not sure I explained my problem correctly so here is an example:
class Bid { // Each new customer bid is stored in this table
String bidName
static hasMany = [ item: ItemList ]
static belongsTo = [ versionNumber: VersionControl]
}
class ItemList { // Products/Services are associated with a bid via this table
String description
static belongsTo = [ bid: Bid, item: Price ]
}
class Price { // The price of individual products and services the company offers
String description
Long value
static belongsTo = [ versionNumber: VersionControl]
}
class VersionControl {
/** So that when filling in the ItemList form for a bid, I can query for only
* prices with the correct version number
*/
String user
Long versionNumber
Date timestamp
static hasMany = [ bid: Bid, productOrService: Price ]
}
This example works fine, and illustrates what I want to do. I just don't know if it is the best way to address the problem and how well it will scale - I have around 20 tables containing different parameters who's versions I need to keep track of.
A bid will always be assigned the latest version of a pricing list, but the user must have the ability to be able to select a different version.
I should probably mention that prices will be updated in bulk, not individually, using a csv file provided by the accounting department. Each csv represents a new discreet price list version, not just as far as the database is concerned, but from an internal management perspective.
A similar philosophy will affect other tables in the DB such as exchange rates to use or geographical regions where the company operates.
The regularity with which new versions are released is also hard to predict which could make determining the endDate a problem.
There is no special Grails support for this goal, this is simly a 4th normal form. In your case it will be a header table for price entity and a subtable for value in time with limits:
class Price {
static hasMany = [ values: PriceValue ]
}
class PriceValue {
Number amount
Date validFrom
Date validTo
static belongsTo = [ price: Price ]
}
I believe ou should not extract Version into a separate entity, while your Price is clearly an Effectivity with strictly given time interval (I assume).
So I propose the following design:
class Product {
// whatever
}
class ProductPrice {
String description
BigDecimal value
DateTime startDate // or use JodaTime Interval
DateTime endDate
static belongsTo = Product
}
class Bid { // Each new customer bid is stored in this table
String bidName
DateTime bidDate // or use createdDate
static hasMany = [products: Product]
static belongsTo = [ Customer ]
BigDecimal getProductPrice(Product p) {
ProductPrice.where{
product = p && startDate >= bidDate && endDate < bidDate
}.find()
}
// or even
static transients = [ 'prices' ]
List<ProductPrice> getPrices() {
products.colect{ getProductPrice(it) }
// or even...
ProductPrice.where{
product = p &&
startDate >= bidDate &&
endDate < bidDate
}.list()
}
}
I would suggest using an oracle database and their "workspace manager" feature (I use it with grails and it works pretty nice) http://www.oracle.com/technetwork/database/enterprise-edition/index-087067.html
This would solve all the requirements you listed: if you "version enable" a table that gives you the capability to create workspaces of the current snapshot of data from the parent you are branching from. All these workspaces can make changes independently of each other and merge back into the main workspace when they are ready (and oracle simplifies the conflict resolution between them). However, not all tables have to be versioned such as your pricing tables so they will be managed regularly.
There are tons of other useful features but it sounds like it's basic functionalities would fit your bill. The only thing special you would have to do is keep track of the workspaces and their states as the application users checkout, merge, and resolve conflicts on your UI.
I am new to database programming and am using sqlite and python. As an example lets say I have a database named Animals.db which I open with and get the cursor for in python. Now if I wanted to separate the animals by species I would have a different table per species and since it can get even more specific I would likely need something more specific than just a table of species.
I am a bit confused on how one allocates the correct data to the correct area of a database, how is it separated. Are there tables of tables?
if I wanted to lets say have a table for every land animal and another for every animal of the sea, but each table would need further specification(homo sapiens, etc), how can I do that?
Now if I wanted to separate the
animals by species I would have a
different table per species
Maybe. Maybe not. You might use a table that looked like this. It depends entirely on what you mean by "separate the animals by species". Here's one reasonable interpretation.
Animal_name Sex Species
------
Jack M Leopardus pardalis
Susie F Leopardus pardalis
Kimmie M Leopardus pardalis
Susie F Stenella clymene
Ginger F Stenella clymene
Mary Ann F Stenella clymene
To find all the Clymene dolphins, you might use a query along these lines.
select Animal_name
from animals
where species = 'Stenella clymene'
order by Animal_name
Animal_name
--
Ginger
Mary Ann
Susie
Start by collecting data. Your goal is to collect a set of representative sample data. Sample data, because the full population is too big to handle. Representative, because ideally it represents all the problems you're likely to run into with the full population. If "animal name" to you doesn't mean "Jack" or "Ginger", but "ocelot" and "Clymene dolphin", representative sample data will make that clear.
Address records are probably used in most database, but I've seen a number of slightly different sets of fields used to store them. The number of fields seems to vary from 3-7, and sometimes all fields are simple labelled address1..addressN, other times given specific meaning (town, city, etc).
This is UK specific, though I'm open to comments about the rest of the world too. Here you need the first line of the address (actually just the number) and the post code to identify the address - everything else is mostly an added bonus.
I'm currently favouring:
Address 1
Address 2
Address 3
Town
County
Post Code
We could add Country if we ever needed it (unlikely).
What do you think? Is this too little, too much?
The Post Office suggests (http://www.postoffice.co.uk/portal/po/content1?catId=19100182&mediaId=19100267) 7 lines:
Addressees Name
Company/Organisation
Building Name
Number of building and name of thoroughfare
Locality Name
Post Town
Post Code
They then say you do not need to include a County name provided the Post Town and Postcode are used.
The BSI have BS 7666 - that covers all addressing. I recommend you look there.
The 2000 version recommends
An address shall be based upon a logical data model comprising the following entities:
addressable object, with sub-types:
primary addressable object;
secondary addressable object;
street;
locality;
town;
administrative area, a.k.a. district;
county;
postcode.
See: http://landregistry.data.gov.uk/def/common/BS7666Address
I don't know whether this is minimal (I doubt it) but the heading on my cheque book says something pretty close to:
Lloyds TSB
Isle of Man Offshore Centre
Peveril Buildings
Peveril Square
Douglas
Isle of Man
IM99 0XX
United Kingdom
This causes fits when I try to enter it into the US banking system.
If I were you, I'd call Royal Mail and ask them... or look on their website for postcode lookup as a best practice.
There's different types of addresses, and each different type has a slightly different structure. Forward sorting offices have a different postal address structure than a residential home with a street number. What if the house has a name instead of a number? There are so many factors to consider.
Since I moved to Canada I had to do something similar and it's far more complicated than a straightforward residential address which generally has:
Street Number if applicable
Street Number Suffix if applicable
House Name
Street Name
Street Type
Street Direction if applicable
Unit Number for flats, townhouses or other types of building/location
Minor Municipality (Village)
Major Municipality (Major Town/City)
County
PostCode
Country if you include Scotland, Wales, Northern Ireland (and now I noticed Eire)
Then you get businesses that have their own Delivery Route, PO Boxes, Forward Sortation Offices...
It gets complicated in a real hurry.
Best bet - give Royal Mail a call and they should be able to give you information on their standard address templates.
EDIT: Your 3 field method isn't a bad one...particularly. However, data sanitization may be a significant issue using the field setup you have and you may need a fairly complex strategy for making sure that the address entered is valid. It's far easier to sanitize single dedicated fields to make sure input is correct than it is to parse various address tokens out of combined fields.
Another simpler way to gain this info is to go on the Royal Mail website and check their postcode lookup page.
On their main postcode lookup, they use 4 fields and I guess they have some form of validation on the street name/type field. They separate the house number and name and I guess they only allow major municipality. I'm assuming the county/country are assumed. If you break out their advanced search, they give you two extra fields for flat number and business name.
Given that some fields are combined on their site, you have to assume that there's some amount of validation to make sure that data entered can be gainfully used.
Premises elements
Sub Building Name
Building Name
Building Number
Organisation Name
Department Name
PO Box Number
Thoroughfare elements
Dependent Thoroughfare Name
Dependent Thoroughfare Descriptor
Thoroughfare Name
Thoroughfare Descriptor
Locality elements
Double Dependent Locality
Dependent Locality
Post Town
Postcode element
Postcode
This answer may be a few years late, but it's aimed at those like myself looking for guidance on how to correctly format postal addresses for both storing in a database (or the likes of it) and for printing purposes.
Taken from Royal Mail Doc, link below - conveniently titled the 'Programmers Guide'
Technical specififcation for users of PAF
Page 27 - 42 was most helpful for me.
It's very likely that a "UK" will be opened to Eire as well, and in some lines of business there will be legal differences, generally between Scotland / NI / the channel islands and England and Wales.
In short, I would add country to the list. Otherwise it's fine (no fewer certainly), though of course any address is traceable from a building reference, a post code and a country alone.
Where we live in France its just 3 lines:-
myname
village/location name
6 digit postcode followed by post town name in uppercase
Even from UK that's all that is required