If I remember rightly it's something like "Wo ist mein Arschloch?" - isn't that right AmmoQ?
zedhex
@zedhex
Best posts made by zedhex
-
RE: Tell me what you think about this...
-
RE: Tell me what you think about this...
Don't you just hate it when someone is soooooo right....
-
RE: Sexism in IT
@dhromed said:
Report it.
This is bullshit.
OK, I'd like to report that anyone applying for the job of "little head polisher" must be female.
Otherwise you'll get a kick in the nuts.
Latest posts made by zedhex
-
RE: MegaUpload Fail.
[QUOTE]Not mediocre. Not at all. They're highly underrated[/QUOTE]
Not by people you know how to play music. It's just the non-musicians who have these funny opinions on stuff like that - and what the hell do they know?
-
RE: Help! Must replace NHibernate.
I'm with jvdl on this one - I find NHibernate's "one-size-fits-all" approach to building a data layer pretty dumb. It also is fiendishly hard to modify once the data layer has been created. I prefer to roll my own whenever possible. Its not that hard to do with VS's support for custom templates. Right now I have templates which create all my CRUD operations in SQL and C# (plus a couple of custom ones) from a single table name. If I need to modify anything, I just edit the generated SQL/C# code from my templates. It takes a little bit more hand-coding than with NHibernate, but the increase in flexibility is well worth it.
-
RE: Toyota's pedal recall: Speculation
@Weng said:
@zedhex said:
re. puny Toyotas: I have a toyota. It has twin turbos and produces 330 hp.
It also wasn't built in this decade.
I also question why your Nova had a 350 hemi. A MOPAR engine in a GM car? A 350 small block perhaps.
You know your cars Weng, it was a small block (and more than fifteen years ago), I stand corrected. My Toyota is a 1994 grey import Soarer - and your right about Toyota giving up on the performance front. Such a shame, as the Soarer, MR2 and Supra were wonderful cars. The only bright spot on the horizon is the Lexus LFA, but who has that much to spend on a car anymore?
-
RE: Toyota's pedal recall: Speculation
re. puny Toyotas: I have a toyota. It has twin turbos and produces 330 hp. Puny, it ain't. It starts first time in -13 degree temperatures and has never, ever had any problems whatsoever it over ten years of ownership. The real problem we have here is the owners. Anyone who finds that a stuck throttle is dangerous simply does not know how to drive/think. If they are so incompetent that they then die as a result, then I say "good riddance to your defective genes, and thank you for cleaning the human gene pool". I once had a stuck throttle on a Chevy Nova with a 350 hemi. Full throttle down the I95 for about ten miles controlling the thing by turning the ignition on and off. It was fun!!!
-
RE: Bought a new car, is the universe telling me something?
If she was, then she's too old to b a 5LUT
Get me an 89 model anyday.
BTW - is the OP's plate for sale?
-
RE: Multilanguage support / internationalization
Just a minor heads up - if you are going to use MySQL in an i18n app, be very careful when searching for text fields. I write my code in the far east and many of the languages around here (Thai, Japanese, cantonese etc.) require unicode AND the correct collations to be set. If you don't get it right, then you'll find that you cannot search on text fields correctly. I generally recommend using a binary collation for non-Latin based languages.
-
RE: Database design... use XML column?
@Abbacabba said:
I'm actually building out the seperate tables design right now to see how it works..
Here is what I'm looking at right now :
products { id(PK), customerID(fk), description }
customer_jobs { id(PK), jobID(fk), customerID(fk), productID(fk), address1, address2, city, state, postalCode,country, customerDataID(fk), status } <-- "main data table"
customer_customerDataTable {customerID(fk), productID(fk), customerDataTableName} <--- PK will most likely be autogenerated.
CustomerA_P1 {id(pk), a, b, c, d, e} <--- customer A, product 1 table
CustomerA_P2 {id(pk), a, b, f, g, h, z} <-- customer A, product 2 table
CustomerB_P1 {id(pk), j, e, c, y, p} <---- customer B, product 1
Still a WTF design?
And also :
Here is an example of afew data lines I might receive (comma delimited):
Customer1 : 123 Main St., SomeCity, TX, 12345-1234, MemberID, Message, MemberPin
Customer2 : 987 1st Street, City2, VA, 54321, eyeColor, Height, Weight, Sex
Customer 3 : 21 Jump Street, New York, NY, 22222, badgeNo, Classification, Rank, DepartmentNo, DeskNo, licenseToKill, statusAs you can see, all the data records contain mailing address information, but each customer also sends in number of other pieces of information for a record. Also the number of pieces of data beyond address info a customer sends is customer specific, one might have 3 fields while another might have 12 or 20. (in the above examples Customer3 has many more fields than 1 or 2, and no customer sends in the same data items.)
Yes, it is still a WTF. One of the main precepts that E.F.Codd came up with (he was the guy who originally came up with the idea of relational databases) was that all fields in a table should relate directly to the PK. This means that your CustomerJobs table really should not have address data in it. Far better to have separate Customer, CustomerAddresses (in case your customers have more than one address - I know all mine have), Products and then specialized Customer tables as mentioned previously. The you'd add your CustomerJobs table as a junction between the Customers and Products tables. It also looks as if you will need to parse and validate your data to load the database correctly (EyeColor??? - why do they want you to know that?).
Looking at your example data is just depressing - why is it that customers never have the first clue about organizing data? - oh yeah, cos they aren't tech people.
But we don't have that excuse.
-
RE: Database design... use XML column?
@Abbacabba said:
I've gotten the rest of my schema mapped out, and it followed a pretty easy design... Its just this damn main data issue, its the only real point in the process where data will be "unique" per product. Like I stated in my previous post(s), my developer side is wanting to jam it into a single table, the DB design side says there is most likely a better design... I'm just trying to find it.
The only problem I was running into was how best to store the actual customers data everything else is pretty much the same for all customers.
I thought about haveing the "main" or "master data" have a column that would "point" to the customers unique table, but is this a good/bad thing?
Example :
Data {dataID(PK), customerID, address1,address2, etc..., customer_data_table} (or have a seperate table... XXXX { something(PK), customerID, ProductID, customerDataTable} )?CustomerA_Data
{ dataID(FK), customerDataID(PK), customerdata1, customerData2, customerData3}
Is this what your talking about? (again just an ugly quick try)
Thats pretty much correct. Using master table/child tables is often a reasonable approach when designing a solution based on data specializations. I tend to use it a lot, especially in combination with a Linq-est object model. Just derive your business classes from a common base class. The base clase would be hydrated from the Master table, and the child tables would be based on one of the Child tables. You would have to add your own data-layer to control selectively loading the correct data, but that isn't too much work. Extending the schema is then just a matter of adding a new child table and corresponding class. All the other code would be blissfully unaffected.
-
RE: Change = Complaints + Complaints + Complaints?
FWIW - I am so completely unaware of design stuff (sorry to all you oh-so-hip design dudes out there), that I really hadn't noticed anything had changed until I read this thread.
<sarcasm>Can anyone tell me why designers get paid almost half as much as programmers? What for exactly???</sarcasm>
-
RE: Database design... use XML column?
If I had a buck for every piece of god-awful code I've seen that started like this I'd have, ... well, enough to get seriously drunk..)
The best advice I can give is start reading up on basic database design. Don't ever get the idea that db design is something you can just <<do>> without some very serious thought. As a basic first step, you need to model all the data entities and their relationships. Find where they have commonalities and differences. Then draw them up as a schema and start imagining use-cases. If you schema can handle all your various use cases, you have your first candidate. From reading your ideas, I think you will have complete mess if you try putting disparate data into one single table. Much better to abstract out the commonalities into one master table, and then create specializations in related tables. Then add a specialization field in the master table (maybe call it "CustomerType"?) and use it to ensure that the correct customer data goes into the respective specialized table. That way you will find that your data more correctly models your problem space.