Is this Data Structure OK?

I come from a PHP and Wordpress background, who organize their data collections in to:

  • Posts
  • PostsMeta

All things are essentially a post.

A new article is a Posts with a value of type:“article”.

A new ecommerce product is a Posts with a value of type:“product”.

So I have replicated this in Meteor, and it works very well. I have two collections called Posts and PostsMeta. I’m even thinking about ditching PostsMeta sliming down to just Posts.

So, at various points in the application, I am doing things such as:

	groups() { 
		// Find all the groups on screen, then find our membership status
		var groups = Posts.find({type:"groups"});
			Meteor.subscribe('postsmeta', 'group_meta', group._id );
			Meteor.subscribe('posts', 'group_member_by_group_id', Meteor.userId(), group._id );
		return groups;

But this is a helper, and it seems it may be causing my application to re-render during certain points of the application.

So what’s the verdict?

Have a made a great mistake? Should I separate everything in to hundreds of Collections, or is this data model efficient as I hope it may be?

Thank you, Andy from

I wouldn’t subscribe in a helper. I’d use Template.groups_all.onCreated to manage subscriptions.

I’d also pull out the _id values from the groups as an array and subscribe using that array, rather than doing a subscription for each individual group.

The data structure of posts and postsMeta is find, but could you not return both cursors from the same publication, rather than subscribing to each individually?

Hrm good ideas.

The data is dependent on what the user is currently looking at.

Let’s say we have a Group. It has 10 members. Each member has a role.

My logic is:

  • Find the Group
    ** Each Group
    *** Find Member
    ****Each Member
    *****Find Role

See that? So how can I possibly subscribe to the role, when I don’t have the group? On the other hand this schema is designed on the fly, so perhaps optimization is still quite possible. I’m still learning Meteor, which hurts my brain some times.

Method 1: Okay, but wouldn’t recommend it

Throw some autoruns with subscriptions in the template’s onCreated and use ReactiveVars (also attached to the template in the onCreated callback) to trigger the autoruns.

Method 2: Better

Subscribe using the group id as parameter. In the publication, find all the members of the group, using the group id, find the members’ roles, and return both members and roles cursors in an array.

1 Like

Ahhhh very nice.

So my database collection model is OKAY, just needs to be optimized for speed and calls.

Thank god. I was pretty scared I had jumped the gun.

I go to Dragons Den this Saturday to see what they think. Trying to make this perfect…!

Aha! Here’s how to do it. I can now clean up a bunch of code and reduce overhead on the subscription model.

Meteor.subscribe('posts', 'group_by_slug',  ToSeoUrl(Router.current().params.group_slug) );
var group = Posts.findOne({type:"groups"});

Meteor.subscribe('posts', 'groups_project_category_by_id',  group._id );

Hope this helps some one in the future.