The scenario is that I have a Projects list and there are a bunch of different SPFieldUser fields associated to it. I have another list representing the Project's Logbook (it contains a bunch of data about different milestones of the project). The relationship is like this: (1 project list item : 1 logbook list).
I have to store some metadata in a logbook's list item that points to a specific user, stored in Project's list item. For that I have to create a choice field which represents different SPFieldUser fields from the project's list.
The question is which is optimal way of representing such a structure?
I can just hard-code a choice option for every SPFieldUser in a Projects list, but then when I have to reference this data in a code, I'll have to somehow transform the choice's value into internal name of the associated project's field.
I can also create a lookup of those fields and this way, accessing it is easy. I can show the Title to user and have the internal name stored in a lookup.
I was also thinking about defining some kind of custom FieldType, but I feel like it would require far more work than an of the other methods.
So which method do I choose? Can someone probably suggest a better way?
Lets check out your options one by one in terms of efforts and scalability.
1 Hardconding option : High efforts [Not at all recommended]
- Column needs to be updated when new user joins or user leaves the
company.
- Once format of data is specified its difficult to change. [e.g. FirstName+Lastname or Empid]
Highly recommended OOTB option : very low efforts
Configurable [Please check if you can change format of user data once added as lookup column.]
Custom column type will take coding efforts.
My recommendation is 2nd OOTB option. If you find some flaws in 2nd option let us know we can look for soultion.
Related
I have worked on Azure Search service previously where I created an indexer directly on a SQL DB in the Azure Portal.
Now I have a use-case where I would want to ingest from multiple data sources each having different data schema. Assume these data sources to be 3 search APIs of X,Y,Z teams. All of them take search term and gives back results in their own schema. I want my Azure Search Service to be proxy for these so that I have one search API that a user can use to get results from multiple sources, ordered correctly.
How should I go about doing it? I assume that I might have to create a common schema and whenever user searches something, I would call these 3 APIs and get results, map them to a common schema and then index this data in common schema into Azure Search index. Finally, call this Azure Search API to give back the results to the caller.
I would appreciate any help! If I can get hold of a better documentation for doing this work, that will be great as well.
Your assumption is correct. You can work with 3 different indexes and fire queries against them, or you can try to combine all of them in the same index. The benefit of the second approach is a better way to implement ordering / paging as all the information will be stored in the same index.
It really depends on what you mean by ordered correctly. Should team X be able to see results from teams Y and Z? The only way you can get ranked results like this is to maintain a single index with a common schema containing data from all teams.
One potential pitfall with this approach is conflicts in the schema. For example if one team requires a field to be of a specific datatype or use a specific analyzer, while another team has different requirements. We do this in our indexes, but with some carefully selected common fields and then dedicated fields prefixed according to our own naming convention to avoid conflicts.
One thing to consider is the need to reset the index. If you need to add, change or remove fields you will have to delete the index and create it again with a new schema. If you have a common index and team X needs to add a new property, you would need to reset (delete and create) the common index which affects all teams.
So, creating separate indexes per team has its benefits. Each team can have their own schema without risk of conflicts and they can reset their index without affecting the other teams.
I'm looking for cross site lookup values from one site to another site in SharePoint Online. is it possible to achieve this? if yes, could you please guide me the steps to perform this task.
It is not possible to use list items values from one site as options in lookup column in a list on a different site, without any customization. I think what you could be looking for is term management and manage metadata columns. Term store management is something you create for a tenant level. In a very simple explanation you may think of it as a place to create global and hierarchical dictionaries made of terms and groups. Then in SharePoint list or library you may add a manage metadata column that will allow the users to pick values from a specified termstore. You may create this kind of column on any list and any site as terms are available on tenant level.
Please look more into the concept here -> https://learn.microsoft.com/en-us/sharepoint/managed-metadata
And here is an example how to create a manage metadata column -> https://support.microsoft.com/en-us/office/create-a-managed-metadata-column-8fad9e35-a618-4400-b3c7-46f02785d27f
I hope this will be of any help.
Update
within term store you may create a nested structure grouping terms and then when user selects the value he may select from terms in this structure so it may be like a kind of cascading choice but presented differently. I am not sure if it will meet your needs
We're building a database of cars and their properties, supposed to be stored in a DynamoDB.
Creating a cars table and filling it with objects that has properties like brand, model, year etc is easy.
But we also want a few other features en the admin interface:
Suggestions when typing
When creating a car, it should suggest brand and model from existing cars, when typing in the field.
Should we then maintain a list of brands and models in another table, and make a query to that table, when the user types?
Or is it good enough to query the "rich" table of car definitions, and get all values for brand, all model values where brand has a certain value, etc? My first thought is that it would be a heavy operation and we'd want a separate index of cars and models. But I'm not a NoSQL expert...
Best matches
When enrolling a new car in our system we want to use use an existing defined car as a reference if possible.
So when the user has typed in a brand, model, year etc we want to show a few options of the best matches - we can accept that they year etc. is different, but want the best matches first.
What is the best way to do matches like this on data in a NoSQL database? Any links to tools, concepts etc. will be appreciated :)
Thanks in advance
In dynamodb (all nosql), the less you create tables the best is your architecture (this is one of the main reason we use nosql), so no need of a new table, just add a new attribute and fill it with the searchable data you want, just have in mind that querying by dynamodb is case sensitive and you only can use the begins_with or the contains function to query data
The cons are :
You will use lot of reading capacity unit
You have to manage the capital letters
You have to fabric at each creation the searchable attribute
The solution I suggest is using aws cloudsearch, which gives an out of the boxes suggester, you will will have better results and give a better user experience, the indexation in cloudsearch is automatic each time you have a new item, but be aware of the pricing, however they will give you 30 day for free
This is a simple requirement: I want to add a set of strings to Accounts in Dynamics 2011. The string are external IDs for other systems. All the strings should be unique accross all entities.
The only way I can see to do this is define the strings as entities (say 'ExternalCode') and set up a 1:N reslationship between Account and ExternalCode, but this seems incredibly overweight. Also, defining as an entity insists thhat I give the 'ExternalCode' a name, which it obviously doesn't have.
What's the best way to implement this?
Thank you
Ryan
It may seem overweight, but think about entities as if it were tables. Would you create a second table inside MS SQL? If so, then you should create another entity. CRM is very well optimized so I wouldn't worry about this additional overhead.
Alternatively, you could always carry the GUID in the other system.
How are these unique references entering your CRM system. Are you importing the data from each of the external systems? If so I assume the references are unique in the external system? Once imported you want to make sure that any of these references are not duplicated?
Additionally, how many strings are we talking about here? If it is a small number then it would make sense to just define attributes to manage them and check for duplicates in one of the following ways:-
1) Some javascript could be used to make an oData query to confirm the 'uniqueness' of your external reference number before the record is commited. (But, this is not sufficient is records will be created programmatically in the system also).
2) A plug-in which fires on pre-create to again query the system for other records which match the same unique reference numbers and handles the event of a match accordingly.
However, if there are many of them then it may make more sense to define a separate entity as you say and then as above you could associate a new 'reference record' with the entity via a plug-in, but again, check if the record already exists and then either handle an exception or merely associate with an existing record if that is appropriate.
I think they key is what you want to do if you do find a duplicate and how these records are going to be created in the system (e.g. via UI or programmatically or potentially both).
Happy to provide some more assistance if you have some more details.
I write database applications for a living that the end user can customize.
Frequently, this means that--leaving the database aside for a moment--some of my notional entity types have a universe or domain that is infinite.
Take name types. You could have a first name, last name, married name, legal name, salutation name, and so on. I am not going to put an upper bound on this universe.
But I do need to find and use certain well-known name types. Let's say display name and sort name, just to keep it simple.
I would also like to be able to query for all name types (i.e. the whole universe) and have my well-known name types returned as well.
There are several strategies for accomplishing this within a database:
Have one name_type table with an id column and a code column. ID values less than a certain amount are "reserved" for use by the system; ID values higher than this are deemed to be user types.
Add a column to the id/code pair that is some representation of a boolean or an int type that indicates what type of row this is (e.g. user-defined or system). Same thing, really; just uses another column to explicitly break out the information instead of overloading it in the id.
Have two tables with perhaps a naming convention: name_type and name_type_system. It is understood or enforced that name_type_system is off-limits to users; name_type is their domain. Queries do a UNION across these tables and applications just "know" to never update the system table.
What strategies do people use? Any war stories? Any particular reasons to pick one over the other? Huge pitfalls I'm not seeing?
Best,
Laird
Of your three ideas the first is often called a Magic Number, http://en.wikipedia.org/wiki/Magic_number_(programming), and is a Bad Thing because any code that doesn't "know" about it can make mistakes. Plus you end up over time realizing, "oops, I need to push the minimum value higher, need to resequence 10,000 existing rows." headaches, headaches.
After that, either of the other two works. But the third one lets you use the DB server to deny insert/update/delete access to the account used by end-users, simplifying code.
The way to decide between option 2 and 3 is to ask, are they really 2 separate things? If they are, they will tend to have different security, different operations are performed on them, one is modified by upgrades, the other is not, etc. If they really are two different things, they go in two tables. If they are two flavors of one thing that are almost always treated the same, they go in one table with a "type" flag, option 2.