... | ... | @@ -35,14 +35,14 @@ For full marks you should explain how and why any techniques or principles you'v |
|
|
- Appropriate notation (and legibility) (1)
|
|
|
- Indication of appropriate integrity constraints, including at least 2 foreign key constraints, and primary keys in all tables (1-3)
|
|
|
- Appropriate data types indicated (1-2)
|
|
|
2. Marks for any of the following or similar salient point, to a maximum of 4 marks:
|
|
|
2. Marks for any of the following **or other salient point**, to a maximum of 4 marks:
|
|
|
- MongoDB is a document-based data store OR
|
|
|
- MongoDB is a 'Not Only SQL'/non-relational solution (1)
|
|
|
- Document-based data stores lend themselve better to horizontal scaling as discrete documents are easily distributed across multiple servers. MySQL does not scale well without sharding logic being built into the application (2)
|
|
|
- Document-based data stores lend themselves better to horizontal scaling as discrete documents are easily distributed across multiple servers. MySQL does not scale well without sharding logic being built into the application (2)
|
|
|
- MongoDB supports data replication, which can help the system maintain efficiency as the userbase grows and there are more simultaneous connections to the database (2)
|
|
|
- MongoDB is better adapted for dealing with big data and analytical types of database queries, which would be required when analysing large sets of learner data (2)
|
|
|
- NOSQL data tends to be serialized by column, which may make query performance increase if the data set is large. (2)
|
|
|
3. Marks may be awarded for any of the following or other salient point, to a maximum of 6:
|
|
|
3. Marks may be awarded for any of the following **or other salient point**, to a maximum of 6:
|
|
|
- The app should be written with portability in mind (1)
|
|
|
- Logic should be separate from presentation (1)
|
|
|
- There would be 'separation of concerns', meaning parts of the app that serve a related purpose are developed and maintained separately. This makes it possible to change/upgrade part of an app without the need to rewrite all other parts. (1-3)
|
... | ... | @@ -53,11 +53,14 @@ For full marks you should explain how and why any techniques or principles you'v |
|
|
### Response A
|
|
|
|
|
|
1. ![](figures/Tattoo_Parlour_2.png)
|
|
|
2. *MongoDB is a more scalable solution because you can distribute data across many nodes in a cluster. You can keep adding more nodes as your data set increases.*
|
|
|
3. *I would suggest they adopt the MVC design pattern which means Model-View-Controller. You would only need to change the model because the rest would still work with any database. You could also use a framework like Django because that already has MVC pattern so you can switch back-end easily. It is also Object-Oriented which means you can change individual bits of the application as the requirements change without changing everything. It also uses templates which keep your HTML separate from the logic.*
|
|
|
|
|
|
### Response B
|
|
|
|
|
|
1. ![](figures/Tattoo_parlour.png)
|
|
|
|
|
|
1. ![](figures/Tattoo-parlour.png)
|
|
|
2. *MongoDB is a more scalable solution because it stores data as binary JSON. Documents also have flexible structure so you can change it later if you get more data.*
|
|
|
3. *I would suggest keeping the codebase really tidy and well commented to make it easier to change things later, especially if another developer was working on it. I would say they should write a function to handle the database connection, and others for fetching the data, so only these functions would need updating and the rest of the application could stay the same. They should make sure that the way they model the data in Mongo documents is similar to the way they did it in MySQL, probably making collections synonymous with tables.*
|
|
|
---
|
|
|
|
|
|
## Task 2: Devise a mark scheme
|
... | ... | |