All,
I've been provided a CSV file of parts that contains duplicates of
properties (e.g. resistors have a wattage, tolerance, and temperature
coefficient property) of those parts that differ by a manufacturer
part number. What I'd like to do is to process this file and, upon
encountering one of t
Gary Chambers wrote:
> I've been provided a CSV file of parts that contains duplicates of
> properties (e.g. resistors have a wattage, tolerance, and temperature
> coefficient property) of those parts that differ by a manufacturer
> part number. What I'd like to do is to process this file and, u
Tim,
Thanks for taking the time to reply!
> | INSERT INTO substitutes ([...])
> | SELECT [...] FROM
> | (SELECT *,
> | ROW_NUMBER() OVER (PARTITION BY wattage, tolerance, temperature
> | ORDER BY part_number) AS RN
> | FROM parts) AS SubQuery
> | W
On 10/08/2010 01:42 PM, Gary Chambers wrote:
> Tim,
>
> Thanks for taking the time to reply!
>
>> | INSERT INTO substitutes ([...])
>> | SELECT [...] FROM
>> | (SELECT *,
>> | ROW_NUMBER() OVER (PARTITION BY wattage, tolerance, temperature
>> | ORDER BY
Rob,
> Perhaps a trade off between nullable fields and redundant types. If
> your original table simply had a nullable column called
> isReplacementFor, into which you place in the subsequent rows the id of
> the first instance found.
Am I misunderstanding you when you're suggesting a table like
Yes. With this you can find all part numbers/supplies which match your
value, wattage criteria in one table. Or exclude any which have a
non-null is_replacement_for value.
If you need to drop the "replaceable" variant, you choose which of the
replacements to promote and update the others to match
Rob,
> Yes. With this you can find all part numbers/supplies which match your
> value, wattage criteria in one table. Or exclude any which have a
> non-null is_replacement_for value.
I understand -- thanks. I have received contradictory advice in a
purely data modeling context. What about the
My understanding was that the values were in fact in the data of the
"replacers". If not, you are correct. In this case the replacers are
more like alias for the only instance you have.
If the replacers are immutable by all means ship them off to some other
table (where I suppose the become poi
Rob,
Thanks for your reply!
> And to your point of self-reference, it would be to a co-worker more
> than a manager. Managers are often not good replacements for workers. :)
:) Absolutely!
I was having a conversation over on #postgresql yesterday about this
and, due to my inexperience with ma
Gross generalization perhaps, but keep in mind what the over app/system
needs of the components. Bounce those off you standard ER modeling
instincts and vice versa and you have a chance!
On 10/12/2010 08:19 AM, Gary Chambers wrote:
> Rob,
>
> Thanks for your reply!
>
>> And to your point of sel
10 matches
Mail list logo
