NoSQL database design problem for notice management app?

I am trying to make a database in NoSQL for learning purpose

Its a simple Notice management (Add/ edit/ Delete notice from notice borad) application in PHP.

I have Memcached (Membase actually) where I can store data as key value pair.

For adding a notice, I am generating a unique id {using uniqueid()function} and storing notice detail in it. But the problem is, 1. How to list all the notices?

I also want to add serial key to Notices. To开发者_运维技巧 do that, I need to know the serial key of last inserted data. 2. How do I find out the last inserted Notice?

If find this question inappropriate, cuz this is somewhat relational datamodel (or you may say, it should be implemented in relational database), please let me know any use case scenario where I can use NoSQL to learn more about it.

Natural connections between entities are relational - so every data model is well designed using relational schema. Almost every nosql schema could be represented in relational data model.

You use NoSQL where using standard relational model is not comfortable (for example when foreign components need to add their own data and you don't know it in advance) or you need better performance and scaling - then you denormalize your data in NoSQL schema.

MongoDB (http://www.mongodb.org/) is a good start point in NoSQL data because it allows you to mix denormalized schema with (almost) relational design.

Nice use case is to implement data model for custom form data storing - where number of fields and type of fields isn't known upfront

And about your questions:

1. I don't know membase well but if it's a simple key-value store the only solution is to create another key at which you store list of all id's - but concurrent updates are a big concern here
2. You can also store last insert id somewhere else (at other key) - here concurrent updates are easier to master

The first thing to learn about NoSQL is that there are a lot of NoSQL solutions out there, with different capabilities. You need to pick the one that is most appropriate. In this case Redis will make your life a lot easier with the design that you've chosen.

The heart of the issue is the CAP theorem. Many NoSQL solutions deliberately choose to not guarantee consistency. Once you have thrown that away, you can't guarantee that the same ID is not handed out twice. Therefore it makes sense to either use timestamps, or use something else (like Redis) to generate the unique ids which you can store wherever you want.