I'm in a hypothetical situation in which I need to list students in a school. I have one table view controller that has several sections, representing a school. Each school has subsequent students. Now, I have the requirement to give the user the capability to view all students for a particular school by clicking on the school name in a top level view of my navigation controller.
The question here is, do I branch out my current "StudentsViewController" and add complex logic in order to allow it to display an individual School's students, or would you experts recommend a new class to handle that table?
The tradeoffs are rather straight forward in that I can indeed probably put everything in one view controller at the cost of some confusing/complex logic. On the other hand, there will be a great deal of repeated code if I write another controller that handles an individual school's students.
What do the experts recommend on this one?
I think the simplest thing to do would be to have a single class that handles an array of schools. If that array contains only one item, you can (optionally) have no title displayed for the single section. Otherwise, all sections have titles.
Put all your schools into an array, and when a single school needs to be displayed, stick it into an array by itself, and push that into your view controller.
We do a very similar thing in one of our apps, in basically the same way.
I think it would depend on the model you are using to hold your data.
Lets say you have an array of arrays,
(array of schools, each school holds an array of students.)
In this case, I would stick with one tableController.
The logic doesn't have to be hairy if your model design is simple, and I think it would be cleaner and "more correct" than multiple subclasses in this case.
Don't forget anywhere the system passes you an NSIndexPath you have the section and row numbers. (School and Student)
indexPath.section and indexPath.row
Related
I am working with the core data model in Xcode 5 and I am trying to code an app for school that helps me determine my grades. I need the app to show a table view of each class and then when you select one, it takes you to the next page and from there you can add sections (ex. test, quiz, hw, etc.) and be able to add the percent and grade for each.
Now my question is, should I be using 2 entities or just 1? I was thinking two (class and section) and then just use multiple sections per class. But would anyone advise doing this? If so, how should I go about making the class entity the "parent" or the section entity? or maybe there is a way to do it with just one entity and work with multiple sections within it.. Any advice or answers would be appreciated.
Create two entities (Class, Section) and make one to many relationship between class and section. As each class may have multiple section, relationship is the good approach to do this.
class<---------->> Section
Refer this link for relationship sample.
http://www.raywenderlich.com/14742/
I have a scaffolded Grails application with two domains, Person and Course. Person belongs to Course, and Course hasMany Persons. I have modified show.gsp for Course to list all of the Persons associated with the selected Course.
To achieve this, Course.groovy contains the following line:
List persons = new ArrayList()
And, as a result, the "person" database table contains a persons_idx field. I frequently will be adding new data to the "person" table outside of my Grails application, from an external website.
When INSERTing new data, how to I figure out what to set persons_idx as?
I had originally used a SortedSet instead of an ArrayList for persons, since I care about sorting. But since I am sorting on Person.lastName, and there will always be multiple people with the same last name, then the list will exclude those persons who have the same last names as others. I wish there was another way...
Thanks.
Having two applications manipulate the same Database is a thing to avoid, when possible. Can your 2nd application instead call an action on the controlling app to add a Person to the Course with parameters passed to specify each? That way, only one app is writing to the DB, reducing caching, index, and sequence headaches.
You also state that Person belongsTo Course... so you create a new Person for "Bob Jenkins" for each course that he's in? This seems excessive. You should probably look into a ManyToMany for this.
Without moving to a service, unfortunately, you'd want to change the indices on some if not many of the rows for the children of the Course you're trying to add a Person to, as that index is the sorted index for all the Persons in the Course.
I would suggest going back to a "Set", and do your sorting in the app. Your other question about sorting already told you not to override compareTo to just check the last name. If I were you, I'd forget about overriding compareTo at all (except to check IDs, if you want), and just use the sort() method, passing in a closure that correctly sorts the objects.
I'm programming a website that allows users to post classified ads with detailed fields for different types of items they are selling. However, I have a question about the best database schema.
The site features many categories (eg. Cars, Computers, Cameras) and each category of ads have their own distinct fields. For example, Cars have attributes such as number of doors, make, model, and horsepower while Computers have attributes such as CPU, RAM, Motherboard Model, etc.
Now since they are all listings, I was thinking of a polymorphic approach, creating a parent LISTINGS table and a different child table for each of the different categories (COMPUTERS, CARS, CAMERAS). Each child table will have a listing_id that will link back to the LISTINGS TABLE. So when a listing is fetched, it would fetch a row from LISTINGS joined by the linked row in the associated child table.
LISTINGS
-listing_id
-user_id
-email_address
-date_created
-description
CARS
-car_id
-listing_id
-make
-model
-num_doors
-horsepower
COMPUTERS
-computer_id
-listing_id
-cpu
-ram
-motherboard_model
Now, is this schema a good design pattern or are there better ways to do this?
I considered single inheritance but quickly brushed off the thought because the table will get too large too quickly, but then another dilemma came to mind - if the user does a global search on all the listings, then that means I will have to query each child table separately. What happens if I have over 100 different categories, wouldn't it be inefficient?
I also thought of another approach where there is a master table (meta table) that defines the fields in each category and a field table that stores the field values of each listing, but would that go against database normalization?
How would sites like Kijiji do it?
Your database design is fine. No reason to change what you've got. I've seen the search done a few ways. One is to have your search stored procedure join all the tables you need to search across and index the columns to be searched. The second way I've seen it done which worked pretty well was to have a table that is only used for search which gets a copy of whatever fields that need to be searched. Then you would put triggers on those fields and update the search table.
They both have drawbacks but I preferred the first to the second.
EDIT
You need the following tables.
Categories
- Id
- Description
CategoriesListingsXref
- CategoryId
- ListingId
With this cross reference model you can join all your listings for a given category during search. Then add a little dynamic sql (because it's easier to understand) and build up your query to include the field(s) you want to search against and call execute on your query.
That's it.
EDIT 2
This seems to be a little bigger discussion that we can fin in these comment boxes. But, anything we would discuss can be understood by reading the following post.
http://www.sommarskog.se/dyn-search-2008.html
It is really complete and shows you more than 1 way of doing it with pro's and cons.
Good luck.
I think the design you have chosen will be good for the scenario you just described. Though I'm not sure if the sub class tables should have their own ID. Since a CAR is a Listing, it makes sense that the values are from the same "domain".
In the typical classified ads site, the data for an ad is written once and then is basically read-only. You can exploit this and store the data in a second set of tables that are more optimized for searching in just the way you want the users to search. Also, the search problem only really exists for a "general" search. Once the user picks a certain type of ad, you can switch to the sub class tables in order to do more advanced search (RAM > 4gb, cpu = overpowered).
I'm developing a rails project where I have one data model with multiple fields that are collection selects. I'd like to create another model to represent all of these collection select fields. So, for instance, my main data model has three collection select fields -- one for county, one for category, and one for classification. I could separate these into three separate data models, but that seems redundant since they all share the same characteristics. They have a type and a value, like a county is a county and it has a value of let's say Sonoma, just as category has a type of category and a value of let's say Winery. If you've ever used Drupal, I'm basically looking for the behavior of the taxonomy functionality.
So you see my dilemma: I need to separate these fields into three separate fields but they have very similar data structures. Any suggestions would be greatly appreciated.
This is a perfect case for single-table inheritance. Your problem is screaming for it.
I have a situation where I have Model A that has a variety of properties. I have discovered that some of the properties are similar across other models. My thought was I could create Model B and Model C and have Model A be a composite with a Model B property and a Model C property.
Just trying to determine if this is the best way to handle this situation.
It's definitely valid in certain situations. Let's say you have a Person class and a Company class, and they have the common properties streetNumber, streetName, postcode, etc. It makes sense to make a new model class called Address that both Person and Company contain. Inheritance is the completely wrong way to go in such a situation.
When properties (e.g. state) are the elements of commonality, I definately tend towards using composition rather than inheritance. When using inheritance, its perhaps best to wait until behavior is the commonality, and overrides are needed now or imminently.
What you're looking at is creating an Aggregate Root. A core paradigm of the Domain Driven Design (DDD) principals.
Certain models in your app will appear to belong "at the top" or "as root" to other objects. For example in the case of customers you might have a Contact model which then contains a collection of ContactPoints (names, addresses, etc).
Or a Post (in the case of a blog), which contains a collection of Comments, a Tite, Body and a TagSet (for tagging). Notice how the items i've highlighted as objects - these are other model types as opposed to simple types (strings, ints, etc).
The trick will come when and how you decide to 'fill' these Aggregate Root trees/graphs. Ie. How will you query just for a single TagSet? Will you go to the top and get the corresponding Post first? Maybe you just wanted to rename the tag "aspnetmvc" to "asp.net-mvc" for all Posts so you want to cut in and just get the TagSet item.
The MVC Storefront tutorial has some good examples of this pattern. Take a look if you can.