Looking for a good way to handle member categories (companies)
I have some 5000 members belonging to 500 companies. At the moment I use a member type property to store CompanyId property, but it is very time consuming to get a list of all members for a particular company.
Here's what I do:
foreach (Member m in Member.GetAll)
if (m.getProperty("companyid").Value==mycompanyid)
do stuff
I have considered other ways to achieve this,
membergroups - seem to be much overhead and still I dont know if it would be quicker.
related nodes - companies are stored in content, but theres nothing stopping me from relating content to members, is it + such a thing would make listing members by company a lightning fast thing, right?
Funny how often oneself finds a solution right after posting a question (that previously seemed to be very difficult) to a forum.
Edit : problem still exists since I do need to search members by property occationally. One particular property is the customer number which I store there. Perhaps the best way is to - also - store them in a external table afterall, and add a pointer to the umbraco node id in that table.
I have recently developed a very similar members area to what you describe.
We have 2 members types - company and employee. Obviously the employees are linked to a company.
The solution we ended up going with was to:
(a) develop a data extract of members and create a custom XML file. The structure of the file mirrors that of the umbraco.config (4.03 version). The data extracts run and rebuild the XML file - the scripts (including SQL query) are running in <2 seconds. We currently have them scheduled to run every 30 seconds on the site with no noticeable site performance degradation.
(b) re-engineer the XSLT search package so that it searches the custom XML file, including custom member property fields (series of checkboxes, etc). The search runs in <2 seconds for a "blank" search across 3,000 company records, so was operating at a satisfactory level.
If you would like to get in touch - refer to my profile for a contact email address.
Good to hear. Your solution sounds very conveniant and "Umbraco-ish".
So I guess you created your own SQL query to extract the member properties, to make it quick enough? I had an idea of adding member data to the regular Umbraco XML file. Dunno if that's advisable / possible. Did you try that?
In our case storing data in separate tables works very good. One reason for that is not all persons are members, and not all companies have their own page. Having a table for all person data also makes the listing of people (in groups / companies) a bit easier (and quicker) I think. Also the data transport from the original off-site database (where all changes take place) works better now.
I'll keep your post in mind for a coming site, thanks for writing.
Yes the SQL was "custom built" - a previous post of mine shows the sql which I discovered from other forum posts - I can't locate the original post to give credit where it is due. You gotta be a bit of a SQL guru to be able to write this stuff - I managed to hack away at it until I got the desired output.
I did not try and append the member data to teh main Umbraco file - simply created separate files for the data and called the respective file from within the XSLT.
I created 2 files - one for employee members and one for company members. And then on the front end displayed 2 radio buttons for the user to confirm the type of search they were doing. This was then the trigger within the XSLT to determine which XML file to read. And from there it was easy enough to "cross link" the 2 files. On a company listing we have a link to "View Employees" - the member ID being the identifier for employees.
Looking for a good way to handle member categories (companies)
I have some 5000 members belonging to 500 companies. At the moment I use a member type property to store CompanyId property, but it is very time consuming to get a list of all members for a particular company.
Here's what I do:
foreach (Member m in Member.GetAll)
if (m.getProperty("companyid").Value==mycompanyid)
do stuff
I have considered other ways to achieve this,
membergroups - seem to be much overhead and still I dont know if it would be quicker.
related nodes - companies are stored in content, but theres nothing stopping me from relating content to members, is it + such a thing would make listing members by company a lightning fast thing, right?
external table - dont want to go there really.
I would be happy to hear your suggestions.
Cheers/
Jonas
Relation it is : http://umbraco.tv/documentation/videos/for-developers/relations/introduction-to-relations http://our.umbraco.org/projects/developer-tools/relation-types
Funny how often oneself finds a solution right after posting a question (that previously seemed to be very difficult) to a forum.
Edit : problem still exists since I do need to search members by property occationally. One particular property is the customer number which I store there. Perhaps the best way is to - also - store them in a external table afterall, and add a pointer to the umbraco node id in that table.
Hi Jonas
I have recently developed a very similar members area to what you describe.
We have 2 members types - company and employee. Obviously the employees are linked to a company.
The solution we ended up going with was to:
(a) develop a data extract of members and create a custom XML file. The structure of the file mirrors that of the umbraco.config (4.03 version). The data extracts run and rebuild the XML file - the scripts (including SQL query) are running in <2 seconds. We currently have them scheduled to run every 30 seconds on the site with no noticeable site performance degradation.
(b) re-engineer the XSLT search package so that it searches the custom XML file, including custom member property fields (series of checkboxes, etc). The search runs in <2 seconds for a "blank" search across 3,000 company records, so was operating at a satisfactory level.
If you would like to get in touch - refer to my profile for a contact email address.
Cheers
Nigel
Hi Nigel
Good to hear. Your solution sounds very conveniant and "Umbraco-ish".
So I guess you created your own SQL query to extract the member properties, to make it quick enough? I had an idea of adding member data to the regular Umbraco XML file. Dunno if that's advisable / possible. Did you try that?
In our case storing data in separate tables works very good. One reason for that is not all persons are members, and not all companies have their own page. Having a table for all person data also makes the listing of people (in groups / companies) a bit easier (and quicker) I think. Also the data transport from the original off-site database (where all changes take place) works better now.
I'll keep your post in mind for a coming site, thanks for writing.
Regards
Jonas
Hi Jonas
Yes the SQL was "custom built" - a previous post of mine shows the sql which I discovered from other forum posts - I can't locate the original post to give credit where it is due. You gotta be a bit of a SQL guru to be able to write this stuff - I managed to hack away at it until I got the desired output.
I did not try and append the member data to teh main Umbraco file - simply created separate files for the data and called the respective file from within the XSLT.
I created 2 files - one for employee members and one for company members. And then on the front end displayed 2 radio buttons for the user to confirm the type of search they were doing. This was then the trigger within the XSLT to determine which XML file to read. And from there it was easy enough to "cross link" the 2 files. On a company listing we have a link to "View Employees" - the member ID being the identifier for employees.
Cheers
Nigel
is working on a reply...