As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm finding that it's difficult to clearly articulate the specific models I want to create at times - especially as projects get bigger and I have to wrap my head around the relationships between everything.
How do you organize your data and user models? Do you sketch them out on paper? Maybe there's a neat tool online?
Yep, I believe good old pencil and paper are the tools to use for that. Keeping in mind that eventually your models will access the database through an object relational mapper, you should think in relations.
Mostly, it is worthwhile to think in relations first and then figure out names for your models. Consider the following case where you need something that stores the following:
posts need to be stored
comments need to be stored
users have to be stored
Now, before you think about how you name each of these, rather think about how they are related. I find that mostly by doing that, you will choose the right names intuitively:
A post belongs to a user, a user has many posts, a comment belongs to a post, a post has many comments, a user has many comments, a comment belongs to a user.
In this last rather intuitive sentence, you have everything you need: names and relations. Rails supports this intuition because it is so idiomatic.
This is as far as planning databases and models goes - if you have an existing application and need to figure out the models' relations, I recommend using a UML (unified modelling language) gem called railroady, which will automatically create a nice graphical overview of your application's data.
I find visualisation to be a huge help in establishing a data model and working on data flow diagrams etc.. Pencil and paper has never worked for me because I get all neatness obsessed and hate making changes and redoing things, and I also don't want to get distracted by moving little boxes around on a screen to make them look nice as it breaks the "creative flow".
I've used GraphViz http://www.graphviz.org/ for this in the past for a number of reasons.
First, I've worked for a lot of companies too cheap to spend money on any software that might accidentally help software development.
Secondly, the text input is distraction free -- it lets you concentrate on content without the distractions. The text input can also be generated by code, so it's been great for (semi)automatic code and schema visualisation.
Third, the input text can be added to the source code repository and commented and change-tracked.
I recently discovered http://graphviz-dev.appspot.com/ which has made it even easier -- don't forget to click on them ad links.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm starting a massive project for the first time. I was supposed to be one of the developers on this big project, and all of a sudden, the lead developer and his team backed out of the contract. Now I'm left managing this big project myself with a few junior developers under me and I'm trying to get a firm grasp on how this code should be broken up.
Logically, to me, the code should be broken up by the screens it has. I know that might not be how it SHOULD be done. so tell me, how SHOULD it be done? The app has about 6 screens total. It connects to a server, which maintains data about all other instances of the app on other phones. You could think of it as semi-social. it will also use the camera feature in certain parts, and it will definitely use geolocation. probably geofencing. It will obviously need an API to connect to the server. most likely more APIs than just the 1. I cant say much more about it without breaking an NDA.
So again, my question pertains to how the code should be broken up to make it as efficient as possible. Personally, i'll be doing little coding on the project. probably mostly code reviews, unit testing and planning. Should it have 1 file per screen, and parts that are repeated should have their own classes? should it be MVC? We're talking a 30k line app here, at its best and most efficient. is there a better way to break the code apart than the ways I've listed?
I guess my real question is, does anybody have good suggestions for books that would address my current issue? code clean was suggested, that's a good start. I've already read the mythical man month and code complete but they don't really address my current issue. i need suggestions for books that will help me learn how to structure and plan the creation of large code bases
As I'm sure you know this is a pretty vague question you could write a book answering it. In fact, I would recommend you read one, like Clean Code. But I'll take a stab at a 10,000 foot level overview.
First if you are doing an iPhone app, you will want to use MVC because that is how Apple has setup their frame work. That means each screen will have (at least) a view-controller, possibly a custom view or NIB.
In addition you will want your view controllers pointing to your model (your business objects) and not the other way around. These objects should implement the use cases without any user interface logic. That is what your view-controller and view will be doing.
How do you break apart your use cases? Well, that's highly specific to your program and I won't be able to tell you with a (lot of) details. There isn't a single right answer. But in general you want to isolate each object from other objects as much as possible. If ever object reference ever other object, then you don't really have an OO design, you have a mess. Especially when you are talking about unit tests and TDD. If when you test one part you end up pulling in the whole system, then you are not testing just one small unit, are you?
Really though, get a good book about OO design. It's a large subject that nobody will be able to explain in a SO answer. I think Clean Code is a good start, maybe other people will have other suggestions?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am developing iPhone app for a web application currently running online.
Current web application uses txt files to keep data. Current system uses its own standard to keep data in files and also made custom algorithm to read and write data in it.
Each txt file is below 1 mb size.
There are lot of data manipulations going on.
So while implementing the same what I want to choose for iPhone app?
In apple website they said that 'SQLite is perfect for low-level relational database work'
https://developer.apple.com/technologies/ios/data-management.html
But in my case it is high level.
So please help me to make a decision. Do I want to manage data in files or sqlite database using core data?
What are the prons and conc of each?
Is there any memory issue or performance issue while using files?
Edit 09/02/2013
Thanks for ur answer 'user76859403'.
Current web application is using database too for saving vital information like member details, login credentials etc. and other stuffs are saved in files. In current system there are different sections and all those sections have several sub sections and related information. Such sections and their details are saved in files. Custom algorithm created just read those files and put all data in cache as records (same as in core data managedobjectcontext) and whenever there is a change in data the whole file is overwritten. I would also like to know whether it is possible to import those classes and algorithms that is using in webserver to iOS, so I can save time rewriting the same algorithm for iOS? Current server codes are in C#
First, I must say that I find it odd that the web-server is storing its data in text files and having customized algorithms to manipulate the data. Giving that lots of data manipulation are occurring, this seems highly inefficient to me; a database would be better in my opinion.
From your side however, it all depends on the data you're processing from the server. You can use the following:
SqlLite or CoreData - Using these approaches is one route to go. But you may have the extra work of sorting out the data into tables etc.. usual database stuff. Refer to the answer on this link to get a better idea on the difference between the SqlLite and CoreData or Google a bit.
Just save the data in files just like its being done on the server. There are several ways to do this including Property List files etc. Here's one method where it's being done using NSCoding.
I would say that the approach#1 approach has the advantage in organization and speed (has the advantage any relational database would have). However, the disadvantage is you will take more time properly setting up this correctly.
Approach#2 might save you time as you would not have to consider structure of data or anything, just dump and save. However, ask yourself, is the size of server data liable to increase? is speed a factor in processing? etc etc.. Think about long term, not just the short fix. This approach is right for you if the data will be relative the same and load is small.
The approach you choose largely depends on your data load and furture project scope (be it quick fix, or longer term improvement of current system) in my opinion.
I'd highly recommend using Core Data if you are dealing with anything "high level". Also checkout mogenerator https://github.com/rentzsch/mogenerator. This great tutorial should help you get started: http://www.raywenderlich.com/934/core-data-on-ios-5-tutorial-getting-started
Johannes
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am building a large web app that will help a "region manager" to manage multiple schools in multiple districts.
In total, there are about 400,000 students & teachers.
On top of managing the obvious things like grades, etc. We will also have to manage attendance (daily).
I am used to building web apps at a smaller scale, which I deploy to Heroku. Given a system of this scale, should I be thinking about using a non-relational DB from now or should I just stick to PostgreSQL and do specific optimizations to ensure high-speed and data integrity?
If it isn't clear, the main concern is one of the system being so slow for managing so many records across so many tables - in a relational db system.
Also, what are some common optimizations I can do to ensure speed - if the recommendation is to use a relational DB? The biggest, most obvious one is using indexes on the most commonly accessed information.....anything else like that would be greatly appreciated.
Thanks.
P.S. My team is split on what we should go with, so you guys will lend a useful voice in helping tip the balance :)
Stick with postgresql. Why would something else be better?
With the little info you provided, I can guess your performance is going to probably come down to two things:
Proper indexes on the right columns
Caching with rails and probably redis
Postgresql offers a datastore on disk. Caching pages with redis allows database queries and rendered parts of HTML to be cached in memory, as to avoid touching disk.
Designing proper indexes is an important part of performance architecture, but you don't design indexes for information, you design indexes for queries. And it has little to do with the choice between relational and non-relational database, since both demand you design "proper" indexes. For more details, see my presentation How to Design Indexes, Really.
In addition to performance, please be sure to consider security concerns. Not that NoSql databases are necessarily bad, but it's different. Approaches to securing non-sensitive data can be different.
If you are storing any Personally Identifiable Information, weigh your options carefully, and if you're not sure what the differences are, go with what you know how to secure.
Also, it might not hurt to consider segregating data - some Relational and some not. If you have the flexibility to architecture the system from scratch, whatever works best in your situation is what's right for you.
Suggested reading:
http://www.darkreading.com/blog/232600288/a-response-to-nosql-security-concerns.html
http://www.darkreading.com/database-security/167901020/security/news/232400214/does-nosql-mean-no-security.html
http://www.bigdatarepublic.com/author.asp?section_id=2759&doc_id=256043
Suggested viewing:
http://www.youtube.com/watch?v=YEhy_SuCrYQ (I love OWASP!)
Facebook runs MySQL. I don't know if 400K people means 400K users for this system: I don't think so, but still Facebook is orders of magnitude greater and uses MySQL.
Here is the fact: scaling is hard. If a NoSQL backend was enough to scale easily, noone nowadays would really start with a relational database, don't you think? I know this is not really an answer to your question, but I think there is simple no answer to this.
Use whatever you are comfortable with, use what excites you most, use what you think you'll be using for the next years, or use what you think it's easy to buy support for. Don't care scalability in the account for this choice, because until you face a problem you can't know how to solve. You can't even know if it exists altogether.
BTW, there are lots of considerations about fault tolerance, caching and other things which will have a way greater impact on your performance than SQL vs NoSQL. BTW, not all relational database engines are the same (neither all of NoSQL datastores are...)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm still new to Core Data, so forgive the question.
I'm building an app that (to make it simple) allows people to "challenge" themselves and others. I need to store locally the challenges the user has already accepted, so that he can browse their details offline. However, when the app is online I'm making requests to the server to display the available challenges, the new details of the already accepted challenges, etc. So some syncing will be needed, but I`m trying to keep that to the minimum.
Now my problem is how to architecture the data. Should I:
(1) Have a core data model only for the data that is stores on the device; then just build model classes for the challenges that are being parsed from the server, and display an array of Challenge objects in my table views?
(2) Have a single core data model for both, but somehow distinguish between the Challenges that are local to the ones that are transient?
(3) Have two persistent stores, one for each purpose?
Options 2 and 3 obviously have the advantage of using NSFetchedResultsController, but may be more complex to code and maintain.
And, as to the syncing problem, should I:
(4) Keep a timestamp of the last time each of my local Challenges were updated, and match these with the timestamps on the server, to see if I need to push new details to the server or not?
(5) Save an array of keypaths and the changes, and then push that to the server once internet connection is available again.
What would be the best approach to solve these two problems.
Thanks a lot!
Since this is a design question and design is an art in a sense that there are always more than one approach, here is what I would probably do.
I would create a model to store both local and available challenges distinguishing them by some property. When there is no network connectivity, I possibly could choose to filter out all remote challenges not to show cached (or transient as you put it) challenges. When the connectivity is resumed or when sync takes place, I would check if I need to update any of the challenges either on the server or locally.
Timestamps is a good way to check for modification time of the entity. If you need to do property by property comparisons for conflict resolution, you could use checksums such as crc32 or md5 hash to speed up comparison of binary data should you have any.
Even with timestamps it is possible that an object was touched, but the values saved remained actually the same, so checksum could be used to detect if actual changes were made to the object. You can use NSKeyedArchiver to serialize an object into an NSData and calculate a checksum on it. I have found this approach reliable.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm new to MVC.
I have read this short bit detailing three ways of dealing with the view model in MVC:
http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
The gist of it seems to me that:
Method 1, pull an object out the database and use it as your view model. Quick and simple, but if you want data from multiple tables you're totally screwed (I can't think of a way around it without Method 2).
Method 2, create a class that has references to multiple objects, and use this as your view model. This way you can access everything you need. The article says that when views become complicated it breaks down due to impedance mismatch between domain/view model objects... I don't understand what this means. Googling impedance mismatch returned a lot of stuff, the gist of it being that you're representing database stuff using objects and stuff doesn't map across cleanly, but you'd presumably have this problem even with Method 1. Not sure what I am missing. Also seems to me that creating a class for each View to get the data you want isn't ideal from a maintenance point of view, not sure if you have a choice.
Method 3, I am still getting my head around it, but I don't quite understand why their checkbox example wouldn't work in method 2, if you added a bool addAdditional to your class that wasn't connected to the domain model.
Method 3 seems to say rather than return the domain stuff directly, just pull out the properties you specifically need, which I think is nicer but is gonna be harder to maintain since you'll need some big constructors that do this.x = domain.x, this.y = domain.y etc.
I don't understand the builder, specifically why the interface is used, but will keep working on it.
Edit: I just realised this isn't really a question, my question is, is my thinking correct?
The problem I've run into with #2 is that I have to do one of these two things:
Include every single field on every single object on the form -- those that aren't going to be displayed need to be included but hidden.
Only include the specific fields I need but use AutoMapper or something similar to map these fields back onto the actual objects.
So with #2 I see a mismatch between what I want to do and what I'm required to do. If we move on to #3, this mismatch is removed (from what I understand, briefly glanced at it). It also fixes the problem that a determined hacker could submit values like id fields or similar when using method #2 that unless I was very careful could be written to my data store. In other words, it is possible to update anything on any of the objects unless one is very careful.
With method #3 you can use AutoMapper or similar to do the dirty work of mapping the custom object to the data store objects without worrying about the security issues/impedance exposed by method #2 (see comment for more details on security issues with #2).
You're probably right about impedance mismatch being present in both Methods 1 and 2 - it shows up anywhere you're going between objects in code and DB objects with relational mapping. Jeff Atwood writes about it, and cites this article, which is a fantastic discussion of everything dealing with Object-Relational mapping, or "The Vietnam of Computer Science". What you'll pretty much end up doing is weighing the pros and cons of all these approaches and choose the one that sounds like it fits your needs the best, then later realizing you chose the wrong one. Or perhaps you're luckier than I am and can get it right the first go 'round. Either way, it's a hairy problem.