Comment On Perseverance in the Face of Change Requests

I guess that's where the phrase "From part's unkown." comes from.

"A part by any other name..."

Parts is parts.

Bartman:

Parts is parts.

Except for when Parts.isNotParts

DELETE FROM emps WHERE stubborn = true

I predict a lot of self-joins in their queries :)

Brevity is the soul of wit ..

captcha, onomatopoeia. cool.

I just got this mental image of a kid too dumb to put the right block in the right hole (you know the toy I'm talking about) so instead it's making it fit in the wrong one with a hammer.

Strider:

Bartman:

Parts is parts.

Except for when Parts.isNotParts

Alternatively:

SELECT * FROM Parts WHERE Parts.isNotParts = FILE_NOT_FOUND.

Normalization is just a fad right? :)

Real programmers don't use databases.

Real programmers don't use data.

Real programmers don't.

Sorry, but I must be slow today. What was the developer's intention with Part.isNotPart? Is that a bool or the assembly name or what?

too embarrassed to fill in:

Sorry, but I must be slow today. What was the developer's intention with Part.isNotPart? Is that a bool or the assembly name or what?

LOL, You mean you don't know?!?!?!?! LOL LOL>> I Bet yoou are not a good programmer. LOL ROFL LOLLOLOL . I am a hxors and I know. LOLOLOL. You are dumb, LOLOL.

captcha: ninjas. YES NINJAS YES LLOLOLOL

Real programmers?

The idea is, rather than handling the concept of an assembly properly, he sets 'IsNotPart' to indicate that it's an assembly rather than a part, unless I'm completely misreading this WTF.

too embarrassed to fill in:

Sorry, but I must be slow today. What was the developer's intention with Part.isNotPart? Is that a bool or the assembly name or what?

Based on standard naming conventions I would say it is a boolean.

Over all not a really big WTF, table name could of been better, you have a seperate table which was used to store the catalog desciption and instead of just carring single parts they are now carring assemblies. Assemblies still need a part number and a description and instead of creating a new table and join them in they just added to the existing tables then in the description table added a column to indicate it is not a part in the way other others are a part.
Most likly this is for an automotive catalog, they still refer to everything as a part even if it an assembly.

Sorry, but I must be slow today. What was the developer's intention with Part.isNotPart? Is that a bool or the assembly name or what?

The purpose was to store assemblies of parts, groups of parts, if you will; think of an assembled radiator with cooling fan and wiring harness. You could perhaps purchase this entire assemblage as one SKU. So, instead of creating a new table, called Assemblages, or something, they added this retarded field to their parts table.

Pehaps if the column was named "IsAssembly" rather than "IsNotPart" there'd be no WTF?

spamguy:

Real programmers?

Real

too embarrassed to fill in:

Sorry, but I must be slow today. What was the developer's intention with Part.isNotPart? Is that a bool or the assembly name or what?

I suspect that, rather than create an assemblies table and a linking table to associate parts with assemblies, the developer simply added assemblies to the parts table with an IsNotPart flag to distinguish assemblies from parts. It's the one-table-fits-all solution.

Good point.

Fredrik:

spamguy:

Real programmers?

Real

GettinSadda:

Fredrik:

spamguy:

Real programmers?

Real

ERR: DIVBYZERO

So if you want a part, you select for NOT PART.ISNOTPART ?

Fr:

too embarrassed to fill in:

Sorry, but I must be slow today. What was the developer's intention with Part.isNotPart? Is that a bool or the assembly name or what?

Based on standard naming conventions I would say it is a boolean.

Over all not a really big WTF, table name could of been better, you have a seperate table which was used to store the catalog desciption and instead of just carring single parts they are now carring assemblies. Assemblies still need a part number and a description and instead of creating a new table and join them in they just added to the existing tables then in the description table added a column to indicate it is not a part in the way other others are a part.
Most likly this is for an automotive catalog, they still refer to everything as a part even if it an assembly.

No really, it is a major WTF.. It's a part by definition of being having a row in the parts table.

Or to put it more logicaly

We have three predicates e.g.

'The Part identified by p_id Can be supplied'
'The Assembly identified as a_id, is an assembly'
'The Assembly identified by a_id Uses Part p_id'

And some propositions...
The Part P1, can be supplied.
The Part P2, can be supplied.

A1 Is an assembly

The Assembly A1, uses Part P1
The Assembly A1, uses Part P2

All makes, sense and everyone can understand the rules here... I hope the corresponding SQL DB design would consist of three tables. (Assemblies, parts, assembly_parts'


Except... according to their design, they simply have a Part called 'P3' which isn't really a part, it's an assembly.... Overall, not very intuitive.

I just have to say I love the title of this article.

No really, it is a major WTF

Please don't get anywhere near my parts database.

An Assembly can be modeled as a subclass (specialization) of a Part. One valid way to map this object model to a relational model is to store the two classes in the same table and use a discriminator column to identify the specific subclass.

The only WTF here is the stupid column name.

Personally, I think that in some cases you could implement the solution with only two tables. Supposing that:
- Every part could belong to an assembly, and assemblies can be sold as parts.
- More than one level of grouping is needed, i.e. an assembly can belong to another assembly as well.

You could use the "Parts" table to store both parts and assemblies, and an "Assemblies_Parts" table to store the relationship.

I had to deal with this kind of structure in the past and the major drawback was trying to avoid infinite recursion, like "Assembly A includes Assembly B which includes Assembly A", but, if well planned, it can be a "general purpose" solution.

Grovesy:

No really, it is a major WTF.. It's a part by definition of being having a row in the parts table.

I'm not sure. We'd need more information really.

This is for a catalogue, so if they have boxes full of parts to sell, and boxes full of pre-packaged assemblies to sell, it's not a WTF IMHO (OK, so the table name could have been something other than 'Parts', but that's very minor).

Eg, if someone sells individual AA batteries, and also sells packs of 4 or 12 AA batteries, it wouldn't necessarily be wrong to have that as three different items with no links between them in a database IMHO.

OTOH, if they just have boxes full of parts to sell, and assemblies are made up of parts at the time of selling/dispatch, then it's a lot more major - eg there would be no way to tell if an assembly is in stock as there's no way to link an assembly to its constituent parts, and packing notes couldn't automatically be produced and so on.

OYAH, if this table had absolutely nothing to do with anything other than generating the catalogue, then it's probably not a WTF from the developer's POV either, but it might be from whoever else decided the data needed entering twice.

K Klein:

No really, it is a major WTF

Please don't get anywhere near my parts database.

An Assembly can be modeled as a subclass (specialization) of a Part. One valid way to map this object model to a relational model is to store the two classes in the same table and use a discriminator column to identify the specific subclass.

The only WTF here is the stupid column name.

Ok, let’s go one step further and introduce components into the mix, along with

Part {Id, description, IsPart, IsComponent}


Or perhaps another parallel

Department, Product Range, Products, SKU's… I really hope you wouldn’t suggest a database design of

Product {id, name, description, size, colour, isRange, isProduct, isSKU, stockCount}

Oh come-fucking-on, not another ZOMG NORMALIZE EVERYTHING WTF...

If asemblies and parts have the same semantics in most of the app, it's much better than creating 2 additional tables and then duplicating half your code

pscs:

Eg, if someone sells individual AA batteries, and also sells packs of 4 or 12 AA batteries, it wouldn't necessarily be wrong to have that as three different items with no links between them in a database IMHO.

Well, in this case.. you have a classic Product, SKU structure

Product - 'BrandName AA'
SKU (what you actually stock) - Single, 4Pack, 12Pack,

Or alternatively, if you store single AA batteries in your warehouse and apply a discount for bulk sales (e.g. 1,4,6,12..) then you would deal with that in your discount structure

K Klein:

Pehaps if the column was named "IsAssembly" rather than "IsNotPart" there'd be no WTF?

Uh, you need a column called 'IsPartOf' containing the ID of another part, if we really wanna get recursive.

Advantages:
* everything a part can do, an assembly can do
* therefore, assemblies can have sub-assemblies

Disadvantages:
* Much Abjuring of Demons required if stupid people get at the database

bdew:

Oh come-fucking-on, not another ZOMG NORMALIZE EVERYTHING WTF...

If asemblies and parts have the same semantics in most of the app, it's much better than creating 2 additional tables and then duplicating half your code

Well, your counter design would end up with a more complex set of constraints. (of the top of my head)

-A Part that is a part must have a parent part
-A parent part cannot be part
-A part that is not a part cannot have a parent part

K Klein:

No really, it is a major WTF

Please don't get anywhere near my parts database.

An Assembly can be modeled as a subclass (specialization) of a Part. One valid way to map this object model to a relational model is to store the two classes in the same table and use a discriminator column to identify the specific subclass.

The only WTF here is the stupid column name.

Right on. If the higher assembly has a distinct part name it belongs in the parts table, with a join table linking it to its sub assemblies, some of which may be parts or other assemblies. Absolutely nothing wrong with it. Fact is, you don't even need that additional column really, since a parts presence in the subassembly join table indicates it is an assembly. This is not a WTF.

CAPTCH "dreadlocks" As a DBA, yes, I do.

Me:

K Klein:

No really, it is a major WTF

Please don't get anywhere near my parts database.

An Assembly can be modeled as a subclass (specialization) of a Part. One valid way to map this object model to a relational model is to store the two classes in the same table and use a discriminator column to identify the specific subclass.

The only WTF here is the stupid column name.

Right on. If the higher assembly has a distinct part name it belongs in the parts table, with a join table linking it to its sub assemblies, some of which may be parts or other assemblies. Absolutely nothing wrong with it. Fact is, you don't even need that additional column really, since a parts presence in the subassembly join table indicates it is an assembly. This is not a WTF.

CAPTCH "dreadlocks" As a DBA, yes, I do.

I'd buy that, if parts and assemblies were the same.. e.g. Parts are made up of parts... Such a database design would make sense. So the WTF is the existance of IsPart and it's name

I just get the impression from Alex's story that they are not..

Another bit that suggests doom is

'strSql = "SELECT...

which implies that Stored procedures happend to other people.. Lots ofAd-hoc queries all over the system (maybe several systems) anyone?

If you're using IsNotPart as a property of Part to define something that it is not, then why stop there?

Part.IsNotBananas
Part.IsNotPenguin
Part.IsNotMohorovičićDiscontinuity

etc.

Fredrik:

spamguy:

Real programmers?

Real

NULL

What is the difference between a part and an assembly?

A part is a single item, while an assembly has a BOM (Bill of Materials). A BOM is just a list of parts or other assemblies.

If the application is some kind of POS or item tracking system, then <sarcasm>"What's the difference?"</sarcasm>

If the application is some kind of Manufacturing MRP, "Get out now while you still have a chance."

Crash Magnet

They decided to start storing customers in the table too. To get a list of parts:

Part.IsNotPart = 0 AND Part.IsNotCustomer = 1

//Please note Customer name is stored in part.description.

bg:

Real programmers don't use databases.

That was also the lead programmers opinion. It's most often bad if a programmer designs a database.

spamguy:

Real programmers?

Real?

Really, there's not enough information here to say if this is a major WTF. I can certainly imagine that this is a literal-minded O-R mapping. Assembly could easily be a subclass of Part, and they get used in similar ways in the application (think "we sell both assemblies and parts, we just shown them on different screens"). So the quickest way to persist them both would be to put them in the same table and add a column to distinguish the subclass. If that's the case, then at most this is an issue of a poorly-named column.

On the other hand, if Assemblies are treated by the software as collections of parts or nested collections of parts, then you do need a more complex schema to describe it properly. But the submission doesn't show us any more of the schema, so we have no idea how (or if) that's implemented.

For stories like this, I'm always suspicious that the submitter simply didn't understand the software design in question.

I decline to omit an opinion before knowing about the time frame. If I was working in this project for 3 months and someone came up with a 'Change Request' to support Assemblies 1 week before going live, I would go with the extra column (and call it IsNotFxxxPart)!

spamguy:

Real programmers?

Yea its those programmers that work in Madrid.

bdew:

Oh come-fucking-on, not another ZOMG NORMALIZE EVERYTHING WTF...

If asemblies and parts have the same semantics in most of the app, it's much better than creating 2 additional tables and then duplicating half your code

You are correct, sir. I'm am living this nightmare right now in my current job. Three large tables; every significant piece of SQL requires two UNION statement; every significant piece of Java requires conditional logic.

If this wasn't enough, the view layer uses a technology that allows conditional logic. So every significant display template also uses conditional logic.

I pity the foo' who thinks this WTF is really a WTF!

Fredrik:

spamguy:

Real programmers?

Real

Top