Excellent.
Thank you very much. I owe you one piece of WTF code.
Excellent.
Thank you very much. I owe you one piece of WTF code.
Hi Alex,
So this method would essentially take all the non-North American countries and put a placeholder for each country in the regions table, correct? I'm not experienced with 'best practices' (and my employer is definitely not), but is this the 'standard' way to depict what I'm after?
Thanks again
Ninja Edit : I can't use any free list unless it also appears in french. Hooray for bilingualism.
The error was in the nomenclature. The data is not to accurately depict the globe, or specific areas, but to pin down a location with a workable address. The 'region' will be represented by either a province or a state if it is North America, but would not be necessary if it is in England, Italy, Germany, etc.
I am trying to avoid some non-standard bizarre design, which is why I am here. The reason that we will not be recording any of the misc sub regions of non-north american cities is the data is not needed, and would be missing from the physical requests.
Again, if I am not clear, here is what is being represented in the transaction -
Request1 - {some data} , Ottawa, Ontario, Canada
Request2 - {some data}, Berlin, Germany
Both of these are 'complete' records. We don't need to know which burrough in germany it is (or districts, I can't remember which they have), but we do need to record that Ottawa is in Ontario. I am hoping to find a solution that does not require the transactional records to contain cityID, provinceID, countryID, but instead only have cityID and have the relationship within the city/province/country tables. This would be easy to do if it either did not require non-North American data, or if each Non-North American country had a concise province/state breakdown that we could use. Even if we included the 'burrough ' in the province table for germany, since our requests would not contain the 'burrough', only the city and country, it would be difficult and time consuming to find the correct one (or throw code at - neither of which I want).
Anyway, thanks again for your help, and I hope I have been clear in regards to what I am looking for
Hi Again,
The majority of the data WILL have regions associated with them (either province or state), as it will be mostly NA data. The execption is the non-na data with no region associated.
So your suggestion is to have the city table containing both FK for country and province and not have a country link in the province table (or have one to filter lists).
What I need to represent is something like Ottawa/Ontario/Canada, or Berlin/Germany. I didn't want to include city/province/country in the transaction records, hopefully just the city ID.
And as for creating a region that is the same as the country, I did not want to do that, as I would have to duplicate all the non-NA data in the province (region) table to link it to their country.
Thanks again
Hi Alex,
I won't be requiring country groupings, but I will need non-NA data.
I don't seem to 'get' your solution, unfortunately. Without adding either a redundant 'country_code' field to city (for those that don't have a region), or putting in a flag the table to denote the region_code points to country instead, how do I set the join up for the view?
In case I was not clear enough, I need to record a building in its location around the world. I'd like the data to resemble something like {address Data, City, More Data}, but that won't work out for non-NA cities unless I figure a way around the city->region->country link. The other alternative is {address data, city, region, country, more data}, but I want to avoid that if possible.
Currently the structure I have is what you posted above, but there is no direct city->country link, but I will need to represent one somehow.
Thanks again
I'm trying to find a solution for this that doesn't include a horrific workaround or a transactional record.
I am doing up a db that includes the city-state-country tablesets, but I will need to include non north american data, which will not have a state. Ideally I would like to have only one link in the transaction - city, but so far this would not work with non-na data.
Things I've considered :
put all three in, autofill those that are north american
place flag in city table to denote non-na
duplicate country data in province, linking the countries
So far the only viable option is the first one, as the others have much larger chances of ballooning out of control.
My question is - what is the best practice for this? Has anyone come up with an elegant solution that doesn't require horrible workarounds or increase maintenence?
Thanks
I admit that when I took my whmis training (which was dumb in itself as I worked in an arobics studio with no access to chemicals of any kind), there were people taking notes. I was quite shocked.
What, I thought Skull and Crossbones meant it was Pirate Fresh!
TRWTF is WHMIS itself. In theory it may be a good idea (may?) to teach people about the different warning labes and what they mean, but in practice (in my experience), its always come down to the same idiotic instructions :
Skull and crossbones means dont drink.
A picture of something exploding means that . . . this something can explode.
Well hooray for WHMIS.
I put my cv into a temp company that often staffed IT contractors to the government. I put in my salary reccomendations (a modest $20/hour), as well as my brief work experience (basically a college grad with one post grad IT job), and the ONLY job they sent to me was for
"a note taker for a few hours each thursday afternoon. $7/hour. Perfect for your high school student looking for their first part time job".
I have cable, and was dissatisfied with the complete lack of customer service I was receiving, as well as the high price (I had TV/Internet/Phone), so I decided to shop around. I found that bell (in my area we have two options, one phone - Bell, and one Cable - Rogers) could do pretty much the same thing but for 60 bucks less. I would lose some bandwidth (10 down goes to 7 down), but overall it looked comparable. So I had to give it a try.
Made the order, and with the ever-present snafu's (not a wtf in itself, they're expected at this point), I have to call to get a modem appointment. They tell me that ... a month and a half is their first evening/weekend appointment. Maybe you need to hire more staff? I try 'any time' appointment. Ok, a month and a week now. Yay. Good thing they can just ship me the modem.
So I get all this set up - to initialize the modem you have to ... load up a fucking internet browser. wtf is that?
Next, I get it going, and the first thing I do is go to speedtest.net. 2300 down, 478 up. Not quit 7/1. Retest, then call.
The first brilliant comment I get from the guy is that the package advertises speeds "up to" 7 down. I tell them that that is a fairly liberal use of the terms 'up to', and what, exactly, should I expect if I ordered some of the cheaper packages that advertised speeds "up to" higher than I got? So I keep jumping through hoops, and find out, low and behold, that I cannot ever exceed 2300 down - I'm too far from the centre. This, after they garunteed me that I could get 7 down / 1up.
So that was my 20 minute experience with DSL. Never again.