I have a site that I’m working on the data structure for… I feel like I know how I’d do it, but I was told that it might not scale well, so I thought I’d run it through you guys. In my plan, I was going to make several content types and connect them through node references. Specifically, there would be Content Type A (CTA) pointing to CTB, pointing to CTC, that points to several of CTD’s, E’s, etc. So it could be a Store that has Departments, and each Department would have one or more Budgets, and each Budget could have several items figured into the budget, from an Employee (another content type with items of info) to Custodial (another content type with specific items), etc. Would this cause too much server load using inherent Drupal Content Types with CCK fields (D6)? Would it only work with direct db queries and mysql tables instead? How much is lost doing it using content types instead of custom coding? I guess I was under the impression that Content Types were very efficient, that if you create a Content Type, it is basically the same as creating a specific table in the database, but maybe not. Any advice is appreciated. Sorry for rambling on with specifics. If you need more info, feel free to send me a direct email. Joel
Nodereference fields are useful to create the types of relationships you are describing. Would this cause too much server load using inherent Drupal Content Types
with CCK fields (D6)? Would it only work with direct db queries and mysql tables instead? How much is lost doing it using content types instead of custom coding?
The advantage of nodereference fields is that you can leverage the utilities Drupal provides for nodes, such as revisions, CCK field formatters, and (especially) Views. Views relationships create SQL JOIN statements such that you may select, filter, and sort data across the various references. Were you to do this with custom code, you would have to develop your own CRUD API, fields, formatters, and views handlers. It's a lot of work. I've done it before from scratch and many months later eventually migrated everything to nodes and CCK. When it comes to performance, my advice is to develop the system using the existing APIs as best you can, and then tackle performance bottlenecks as the come up. You may find that the caching mechanisms in place will suffice, or you can develop custom caching solutions, or even custom queries, or manually-created indexes. Drastically changing your development practice for things that "might" occur seems overly-cautious and ineffective. On Thu, Apr 28, 2011 at 2:45 PM, Joel Willers <joel.willers@sigler.com>wrote:
I have a site that I’m working on the data structure for… I feel like I know how I’d do it, but I was told that it might not scale well, so I thought I’d run it through you guys.
In my plan, I was going to make several content types and connect them through node references. Specifically, there would be Content Type A (CTA) pointing to CTB, pointing to CTC, that points to several of CTD’s, E’s, etc. So it could be a Store that has Departments, and each Department would have one or more Budgets, and each Budget could have several items figured into the budget, from an Employee (another content type with items of info) to Custodial (another content type with specific items), etc.
Would this cause too much server load using inherent Drupal Content Types with CCK fields (D6)? Would it only work with direct db queries and mysql tables instead? How much is lost doing it using content types instead of custom coding?
I guess I was under the impression that Content Types were very efficient, that if you create a Content Type, it is basically the same as creating a specific table in the database, but maybe not.
Any advice is appreciated. Sorry for rambling on with specifics. If you need more info, feel free to send me a direct email.
Joel
-- [ Drupal support list | http://lists.drupal.org/ ]
Scaling? How many people are going to use this? It doesn't sound like many; budgets are not generally open to the world, unless it's a government site. So, I supect the first design point is to determine your target audience and how many they might be. Secondly, it's not content types that are the issue; it's nodereferences that are. It might be that you find that some of that is not needed. For example, departmental structure is generally not very fluid, so hand-coding the department names as a list in the content type might reduce the level of performance issues considerably. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. ________________________________ From: Joel Willers I have a site that I’m working on the data structure for… I feel like I know how I’d do it, but I was told that it might not scale well, so I thought I’d run it through you guys. Would this cause too much server load using inherent Drupal Content Types with CCK fields (D6)? Would it only work with direct db queries and mysql tables instead? How much is lost doing it using content types instead of custom coding?
I notice you didn't suggest Taxonomy as a solution for Departments, is that something we can look forward to seeing depricated soon? Are there trends of this kind showing up in Drupal discussions? You know, things on the way in, things on the way out? Perhaps you can give us a list of each? Warren Vail On 4/28/2011 4:24 PM, Ms. Nancy Wichmann wrote:
Scaling? How many people are going to use this? It doesn't sound like many; budgets are not generally open to the world, unless it's a government site. So, I supect the first design point is to determine your target audience and how many they might be. Secondly, it's not content types that are the issue; it's nodereferences that are. It might be that you find that some of that is not needed. For example, departmental structure is generally not very fluid, so hand-coding the department names as a list in the content type might reduce the level of performance issues considerably.
/*Nancy*/
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
------------------------------------------------------------------------ *From:* Joel Willers
I have a site that I’m working on the data structure for… I feel like I know how I’d do it, but I was told that it might not scale well, so I thought I’d run it through you guys.
Would this cause too much server load using inherent Drupal Content Types with CCK fields (D6)? Would it only work with direct db queries and mysql tables instead? How much is lost doing it using content types instead of custom coding?
Nope, just an oversight in haste. It would work as well, and could have some advantages (think about some of the data being a field of the term). I seriously doubt Taxonomy is ever going away - it's a highlighted feature of Drupal. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. ________________________________ From: Warren Vail I notice you didn't suggest Taxonomy as a solution for Departments, is that something we can look forward to seeing depricated soon? Are there trends of this kind showing up in Drupal discussions? You know, things on the way in, things on the way out? Perhaps you can give us a list of each?
So, if there were “many to many” data structures along with “one to many” structures (which node references are, if I understand them correctly), do I lose performance doing them with node references rather than hard coding the schema and interaction and storage? Basically, if I have the data structure and interaction already mapped out, and all the tables already designed, how much performance do I lose by setting up Content Types and Node References versus just creating the table manually, and writing PHP to control the data flow? Time-wise, I realize it’s much, much easier to do Content Types and Node References. It’s like 1/10th the time. But if Node References are going to hit the memory on the server too hard and cause performance issues and delays, then it just isn’t going to work. Thanks for the feedback on this, by the way! I really appreciate it! Joel From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Ms. Nancy Wichmann Sent: Thursday, April 28, 2011 6:25 PM To: support@drupal.org Subject: Re: [support] General Drupal question Scaling? How many people are going to use this? It doesn't sound like many; budgets are not generally open to the world, unless it's a government site. So, I supect the first design point is to determine your target audience and how many they might be. Secondly, it's not content types that are the issue; it's nodereferences that are. It might be that you find that some of that is not needed. For example, departmental structure is generally not very fluid, so hand-coding the department names as a list in the content type might reduce the level of performance issues considerably. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. ________________________________ From: Joel Willers I have a site that I’m working on the data structure for… I feel like I know how I’d do it, but I was told that it might not scale well, so I thought I’d run it through you guys. Would this cause too much server load using inherent Drupal Content Types with CCK fields (D6)? Would it only work with direct db queries and mysql tables instead? How much is lost doing it using content types instead of custom coding?
Joel, with all that we say that focuses on performance, there are things that we don't talk about much. Compared to development costs, servers are cheap. Memory is even cheaper. A super high-powered server with tons of memory is going to cost, at most, maybe $10K. Total cost of ownership over the project's lifetime is going to be orders of magnitude higher. The cost of the development and maintenance is most likely going to be, by far, the larger share of the cost. So finding a developer (and others) with a mindset that reduces that part of the cost is imperative. When I develop a site, I focus on several areas: 1) getting myself out the door as quickly as possible (sounds strange to hear that), 2) making the user experience the best that I can make it so that ongoing costs and usefulness are optimal, 3) making it easy for external performance experts to get the best possible results. If your design meets these goals, then go with it. I certainly think that what you've said indicates you have a handle on #1, with at least some of #2 in mind. Drupal's design generally allows for a good portion of #3. You don't need the community's permission to proceed wih your design. Sometimes there is no "perfect" answer. I can categorically state that you understand the end goals of this project better than anyone on this list. It is also my educated guess that you (plural, as in anyone) won't understand all the performance implications until you are much farther along. We can only tell you that such-and-such didn't work for my project, which in reality was different from yours. So do it, learn from it, and share your experiences when it's over. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. ________________________________ From: Joel Willers Basically, if I have the data structure and interaction already mapped out, and all the tables already designed, how much performance do I lose by setting up Content Types and Node References versus just creating the table manually, and writing PHP to control the data flow? Time-wise, I realize it’s much, much easier to do Content Types and Node References. It’s like 1/10th the time. But if Node References are going to hit the memory on the server too hard and cause performance issues and delays, then it just isn’t going to work.
participants (4)
-
Carl Wiedemann -
Joel Willers -
Ms. Nancy Wichmann -
Warren Vail