I noticed that there are many developers who avoid list-type fields, even when the lists are small.
In terms of performance, speed and WU consumption. I would love to know your opinion. Let’s say I have the following structure:
DT Employee:
Field 1
Field 2
Company (list of DT Company)
DT Company
Field 1
Field 2
Employee (DT Employee)
Well, when I reference the DT Employee, I am also loading the DT Company info, as it is in the list-type field, right?
So, now let’s say that Employee 1 has 5 Companies in the list.
When I do DT Employees > Employees (list), I am only referencing these 5 entries that are listed in the field, because it is already filtered by the given Employee.
If I did "Do a Search for... DT Company" and filtered by Employee 1, I will also receive the same 5 entries, but in this case would it have consumed more WUs, more processing by searching the entire list and filtering it?
When you reference the DT employee, you don’t load any connected data, unless you also reference a field of the connected datatype.
If I did "Do a Search for... DT Company" and filtered by Employee 1 , I will also receive the same 5 entries, but in this case would it have consumed more WUs, more processing by searching the entire list and filtering it?
No… you only consume WU for the search itself (which is a fixed cost regardless of the amount of data) plus the amount of data returned. The amount of data searched through is not relevant for WU cost.
Generally speaking, loading data from a list, even a very large list, is faster and less costly in WU than doing a search.
But there are far more things to consider than just that, which means that in most cases, using large lists is not optimal - but it really does depend on how/where/why you’re using lists… plus there are some other disadvantages to using lists to consider as well.
