Skip to content

there is no need to save the ids in both collections for a belongsToMany relation, or am I wrong? #2040

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
elfeffe opened this issue May 29, 2020 · 4 comments
Labels

Comments

@elfeffe
Copy link

elfeffe commented May 29, 2020

I'm doing

$product = Product::where('sku', '0713XX3FF1')->where('store_id', 1)->first();
$category = Category::where('entity_id', 158)->first();
$product->categories()->attach( $category );

And this is saving the related ids on both collections, so if I have 1 category, with 10000 products, the category has an array of 10000 products inside.
What's the reason?
Saving the category inside the product will do the job, or I'm losing something?

@elfeffe
Copy link
Author

elfeffe commented May 30, 2020

Maybe the Pivot table must be optional.
If you have thousands of categories and thousands of documents, you have a problem with the actual behavior.
Documents and indexes are huge

@Smolevich
Copy link
Contributor

@elfeffe is it actual?

@elfeffe
Copy link
Author

elfeffe commented Sep 21, 2020

@Smolevich Yes, I'm using it with L7 (I think package version was the alpha for L7).
The thing is, when you have thousands of relations, you have a field with thousands of IDs.
I think a pivot table will do the job, I don't understand why pivot tables are "prohibited". MongoDB accepts a JSON, and that's great, but relations are also good some times.

You can save, in this example, the category Id inside the product, but if the product is related to thousands of categories you will have the same issue.

I'm resolving it by myself with a pivot table, search the relation there and then load the products with the IDs from the pivot table, and it's fast, MongoDB indexes are great, but not if you have a field with 15000 ids inside.
I mean, I'm not using the belongsToMany relation anymore, I'm using a custom solution with a pivot table.

MongoDB is great because you are not obliged to design a grid, like in MySql, so you use much less tables because you almost don't use relations. But that doesn't mean we can't use relations, they are supported by MongoDB from long time ago.

A pivot table ill be a perfect solution.

A similar issue is the embedded relation, is totally useless because to load the relations takes micro seconds, it seems like someone said "we use MongoDB, relations are prohibited". Maybe they were, but MongoDB supports it from long time ago.

@divine
Copy link
Contributor

divine commented Sep 21, 2020

@elfeffe you have good points, as an example doctrine odm has a few different strategies to save relation data

https://www.doctrine-project.org/projects/doctrine-mongodb-odm/en/2.1/reference/reference-mapping.html#storing-references

I can only agree that all this makes sense, however the problem is here that it's almost impossible to do that without a breaking change release.

This library was written a long time ago and many things has changed even in Laravel itself, complete rewrite from scratch might solve everything but decisions should be made which isn't easy as it looks.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants