0

There are 2 sub-systems[ suppliers and retailers ] in our online market chain management system . Entry in any of those[ suppliers or retailers ] should give a globally unique ID .There would be listing and filtering of each system based on category , locations , nearest retailers .

FYI : The query for listing retailers or suppliers is already complex which uses lots of joins and unions. So, I don't want another table for handling Unique ID .

There is another option to combine retailers and suppliers entry in 1 table. But chances are there it may soon run out of entries if I combine retailers and suppliers entry in 1 table

Individual business entities[retailers or suppliers] have there own accounting system ,product management system , cost management system . So its a bit complex system and some of the query operations are already slow.

I have checked the possible solutions but it wouldn't satisfy our needs because of performance reasons and complexity.

What should I do , should I go for NoSQL , would it solve the problem or Is there any other solution

Improve this question
6
  • Explain "run out of entries". INT UNSIGNED lasts for 4 billion; UUID/GUID lasts for trillions; etc.
    – Rick James
    Apr 21, 2017 at 15:49
  • 1
    You have relationships; so go with a RDBMS. Don't use a NoSQL unless you want to reinvent SQL.
    – Rick James
    Apr 21, 2017 at 15:50
  • Beware of your possible solutions; it is focused on SQL Server, which is rather different (at this detail) from MySQL.
    – Rick James
    Apr 21, 2017 at 15:56
  • I like to prefer auto incremented primary key than using UUID/GUID since it would be faster than GUID and also client mentioned that he prefers Business id as numbers .
    – user7756509
    Apr 24, 2017 at 6:48
  • thanks for suggesting to stay on rdbms . Forseeing the expansion of project from this 2 system(retailer & supplier) to adding celebrities , sport personalities,jobs... as business entities later on in our system as mentioned by client and the need for global unique numerical id, I predicted it would run out of entries if I use same table for entry of all these other subsystems(supplier,retailer,jobs,sports personalities, celebrities..).
    – user7756509
    Apr 24, 2017 at 7:05

2 Answers 2

Reset to default
1

If your requirement is to have global Unique identified for across Entities, you can go for UUID. For more details refer here

Improve this answer
1
  • A caution -- If your table becomes too big to be cached, UUIDs become I/O-bound, hence slow.
    – Rick James
    Apr 21, 2017 at 15:57
0

The whole purpose of a UUID is to

  • ease synchronization between two resources by eliminating the concern of collision
  • to eliminate a locking contention.

If you don't need that, don't use a UUID.

There is another option to combine retailers and suppliers entry in 1 table. But chances are there it may soon run out of entries if I combine retailers and suppliers entry in 1 table

Why would you combine the two? Combining the retailers and suppliers should be done based on the information you capture and how you query that data. Not based on ID-constraints.

UUIDs are used on big sites that view because they NEED them. Not because they want them. If you want to look cool without implementing infrastructure you don't understand or otherwise don't need check out HashIDS.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.