Prisma aggregate sum relation - prisma

I have Quiz model and Question model. The relation is many to many relation. The Question model has point field. How can I sum point field of all question models of each Quiz model to get total points that Quiz model has. I have looked through https://www.prisma.io/docs/concepts/components/prisma-client/aggregation-grouping-summarizing and found nothing about relation sum. Thank you.

Related

UML Class Diagram: Attributes and methods dependant on two classes

I am trying to do a simple UML model about a car dealership.
The company has at least one store where in each they sell at least one type of a car. Each store has a name and each car has a name, type, and price. Each outlet also keeps stock of every car they sell.
I have outlined the idea in this image:
In addition to this, after every day, the number of cars sold gets recorded into a database. How would I add this to the model? Also, is there a better way to model the amount of cars in stock than to have it as a separate class? If there is a better diagram to model this type of scenario with I'd also be interested.
Thanks for any help!
There are many ways to model sales records. The simplest and most common is to have a sales ledger. It creates sales entries for items. The item is a separate (association) class that records the number of sold items, the price paid, the sales date, the sales person, and more. Pretty simple and straight forwards, until you get to the gory details. Ask your next dealer...
You can model a sales record as a separate class. Let's call it DaySales. Each day, you have a new instance of DaySales, containing the date and the amount of cars sold. I have given attribute date the data type 'String', because UML does not define a Date type. But if you define it yourself, you could better use Date than String.
I have removed the association between Car and Outlet, because it is already implicitly defined via Stock, but you can keep it as a redundant association, if you like.
I have altered the multiplicity of the association between Car and Stock, because there will be multiple cars in stock.

Symfony2 Form generation collection

I've started my learning of Symfony 2 a few days ago and I have a problem concerning a form :
I wish to have a webpage on which a teacher could edit the marks obtained by a student to his homeworks. Of course, I have Student, Homework and Mark entities. This last one is the owner of 2 ManyToOne relations with the two first entities.
The basic solution is to create a form for each homework. But on the long term, there will have too much forms on the same page. And by the way, it would be too boring to have to validate each form if he has to change a lot of values.
I think that I have to deal with a field with the type collection but I don't know how to exploit it :
How can I get the homework list (in order to generate a corresponding Mark form) ? And where to implement this task?
How to access to the homework entity's attributes from the view ? For example, to print the homework's dueDate.
Thank's a lot for your answers!

Update a composed entity in greenDao

Let say i have a business domain in which there are two entities, Survey and Question, in OOP terms, the Survey has QuestionsList, the greenDao generation getQuestions method which returns a list of questions resolving 1:M relation from Survey to Question, but there is no method like setQuestions( questionList) which will take a list of question to update. How can i update the questionList for the Survey entity ?
you can use:
getQuestions().add(Question);
but for setting Question parent you should set ParentId for your Question and then add it to QuestionList of Survey. ParentId is the foreign-key of Question which links a question to a survey.
Remember that you must store Question after these changes.

Manually creating intermediate table in a many to many relationship for Core - Data

I'm currenty working with Core-data for an iPhone project.
But I'm a bit confused about one element.
With Core Data currently you do not need to create the intermediate table when creating many to many relationships (its all handled behind the scenes by core data)
But in my case I actually need some attributes on my many to many relationship!
For example
I have a table called Students
and another table called Lessons
a Student can be in many lessons
and a lesson can have many students
Now a standard many to many relationship will not work for me as I actually need to define more details on the join, i.e. StartDate and LeaveDate.
In a standard sql model for example my join table would be something like
StudentLessons (Studentid, LessonId, StartDate, LeaveDate )
I would need these properties as when i'm querying for information I will need the details from the join to filter my results.
How can I create this in core data and also filter for results?
I've seen folks say that you would actually create the StudentLesson entity manually in core data.
Now if I did this would I just have the attributes (Startdate, LeaveDate) and then a one to many relationship from the Student and then the Lessons table?
Student - > StudentLessons
Lesson - > StudentLessons
I guess I'm a bit confused on how I would go about making sure that the relationships and the content of the relationships are setup correctly. (i.e If I add an Student object to the StudentLessons - how would I then assign/add the Lesson.)
Sorry this is my first time playing with Core Data.
Takes a bit o getting used to when coming from a full on sql background.
You are absolutely right. The correct way to do this is to create a new entity like StudentLessons. Let's call it Attendance. It should have the startDate and endDate, and two relationships.
The relationship to the student can be many-to-many, unless it is foreseeable that startDate and endDate are always different for each student. One Attendance with its dates can have many students in it. One student can have several Attendance duties.
Student <<---->> Attendance
Clearly, the relationship to Lesson should be one-to-many. One Lesson can have different Attendance configurations, with different dates. But each Attendance belongs only to one Lesson.
Lesson <---->> Attendance
To address your question, you can make the Attendance attribute of Lesson non-optional (and vice versa), this way it will ensure that each Lesson has at least one Attendance with appropriate dates, and each Attendance has exactly one Lesson.
I think your can remove the link between Student and Lesson. Just assign an Attendance rather than a lesson. If you want a Lesson assigned to a Student without dates, just allow Attendance to have NULL as those properties.
TheTiger,
Just because Core Data will create a join table for you, that doesn't mean you have to use it. Maintaining which student succeeds with which lesson is just the same except you will create the intermediate entity and then use the appropriate setters to build the relationships.
You will have to use more key paths and do relationship prefetching but those are straightforward to do.
Andrew

No-sql relations question

I'm willing to give MongoDB and CouchDB a serious try. So far I've worked a bit with Mongo, but I'm also intrigued by Couch's RESTful approach.
Having worked for years with relational DBs, I still don't get what is the best way to get some things done with non relational databases.
For example, if I have 1000 car shops and 1000 car types, I want to specify what kind of cars each shop sells. Each car has 100 features. Within a relational database i'd make a middle table to link each car shop with the car types it sells via IDs. What is the approach of No-sql? If every car shop sells 50 car types, it means replicating a huge amount of data, if I have to store within the car shop all the features of all the car types it sells!
Any help appreciated.
I can only speak to CouchDB.
The best way to stick your data in the db is to not normalize it at all beyond converting it to JSON. If that data is "cars" then stick all the data about every car in the database.
You then use map/reduce to create a normalized index of the data. So, if you want an index of every car, sorted first by shop, then by car-type you would emit each car with an index of [shop, car-type].
Map reduce seems a little scary at first, but you don't need to understand all the complicated stuff or even btrees, all you need to understand is how the key sorting works.
http://wiki.apache.org/couchdb/View_collation
With that alone you can create amazing normalized indexes over differing documents with the map reduce system in CouchDB.
In MongoDB an often used approach would be store a list of _ids of car types in each car shop. So no separate join table but still basically doing a client-side join.
Embedded documents become more relevant for cases that aren't many-to-many like this.
Coming from a HBase/BigTable point of view, typically you would completely denormalize your data, and use a "list" field, or multidimensional map column (see this link for a better description).
The word "column" is another loaded
word like "table" and "base" which
carries the emotional baggage of years
of RDBMS experience.
Instead, I find it easier to think
about this like a multidimensional map
- a map of maps if you will.
For your example for a many-to-many relationship, you can still create two tables, and use your multidimenstional map column to hold the relationship between the tables.
See the FAQ question 20 in the Hadoop/HBase FAQ:
Q:[Michael Dagaev] How would you
design an Hbase table for many-to-many
association between two entities, for
example Student and Course?
I would
define two tables: Student: student
id student data (name, address, ...)
courses (use course ids as column
qualifiers here) Course: course id
course data (name, syllabus, ...)
students (use student ids as column
qualifiers here) Does it make sense?
A[Jonathan Gray] : Your design does
make sense. As you said, you'd
probably have two column-families in
each of the Student and Course tables.
One for the data, another with a
column per student or course. For
example, a student row might look
like: Student : id/row/key = 1001
data:name = Student Name data:address
= 123 ABC St courses:2001 = (If you need more information about this
association, for example, if they are
on the waiting list) courses:2002 =
... This schema gives you fast access
to the queries, show all classes for a
student (student table, courses
family), or all students for a class
(courses table, students family).
In relational database, the concept is very clear: one table for cars with columns like "car_id, car_type, car_name, car_price", and another table for shops with columns "shop_id, car_id, shop_name, sale_count", the "car_id" links the two table together for data Ops. All the columns must well defined in creating the database.
No SQL database systems do not require you pre-define these columns and tables. You just construct your records in a certain format, say JSon, like:
"{car:[id:1, type:auto, name:ford], shop:[id:100, name:some_shop]}",
"{car:[id:2, type:auto, name:benz], shop:[id:105, name:my_shop]}",
.....
After your system is on-line providing service for your management, you may find there are some flaws in your design of db structure, you hope to add one column "employee" of "shop" for your future records. Then your new records coming is as:
"{car:[id:3, type:auto, name:RR], shop:[id:108, name:other_shop, employee:Bill]}",
No SQL systems allow you to do so, but relational database is impossible for this job.