A customer is upgrading from E9 to E10, and we’re taking the opportunity to rename and restructure their UD fields.
In particular, they have part information scattered among several UD tables, along with maintenance customization in Part Entry, and we want to bring those fields into the Part table.
So, they have about 100 fields to deal with. How many columns can I add to the Part table before performance begins to noticeably degrade?
The Part count is presently about 19K.
Thanks,
Joe
Just my opinion:
After 20 fields, I normally start offering a UD table where the fields are stored as separate records. This keeps speed and storage issues at a minimum.
So Key1 = Partnum, and Key2 = UDFieldname ??
Something like:
Since XYZ-2000 doesnt get painted, it doesn’t need a record for Finish
Exactly. This may be limiting if they need number, date or boolean, but one of the key values could be “type” and a BPM could check if the text matches that “type”.
I would agree the server likely does not care (much), but it’s the number of objects required that starts to become unwieldy.
If the key fields are indexed, will it not matter how many additional columns are present? I doubt that you will see any slowdown with a normal amount of columns. What’s not normal?
1,000,000+ columns lol
I’ve added about 80 UD fields to OrderDtl with no noticeable performance hit. I didn’t run any metrics to be certain, and the data was entirely filled in by a custom-written process, but all lookups and dashboards ran entirely as expected. This was an on-prem client which I believe was on 10.1.500.
