I need the Entity Relationship Diagram for OpenStreetMap. Or something that could make it very easy for me to get accustomed to the design of the OSM database.
There isn't really anything fancy like an ERD for the database. The primary definition of the schema is the rails migrations, which you can find here:
https://github.com/openstreetmap/openstreetmap-website/tree/master/db/migrate
There is also a (hopefully up to date) dump of the resulting schema in SQL form here:
https://github.com/openstreetmap/openstreetmap-website/blob/master/db/structure.sql
Unless you're actually developing code for the OpenStreetMap web site however you probably don't need to know any of this - if you just want to work with OpenStreetMap data you will probably be better off loading the data into a database with a schema targeted at your intended use case rather than one targeted at supporting editing of the data.
Related
I got an existing database with many tables which are accessed using stored procedures only (no O/RM). I'd like to create new tables in this database using Entity Framework and the Code First approach.
Do all the tables in my existing database need to be modelized in my Entity Framework classes? Will I be able to hand-code only the new classes I need in my DbContext? Other tables really need to stay untouched and away from O/RM for the moment.
Note: I'm going to be using the latest EF5.
As for now the Power Tools only allow you to reverse engineer all tables and views in the DB, which can be a problem if you have a big DB, with hundreds of objects, you do not want to reverse engineer.
However, I found an easy workaround for that:
Create a new technical user for the reverse engineering. To this user you only grant permission to the tables and views, that you want to be reverse engineered.
Have fun!
You are under no obligation to map any given table with EF. If you already have a database, you may want to consider reverse-engineering your database with the EF Power Tools available from Microsoft. I did this recently with a MySQL database that I had for testing purposes and it worked quite well!
If you are new to EF an advantage is that the PowerTools write a ton of code for you, which will help you get a grasp on the syntax of Code First. You will need to modify the output but it is a great start. I really believe that this approach will give you the least headache.
The EF PowerTools can be found here: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/
I like working with the entity framework for many reasons- the ease of use of the entity designer, the power of linq, and the ease of binding.
Occasionally I want to build a simple app that doesnt need to use a database, but still needs to work with data and display it on screen, in grids etc, so I'd like to just create a quick EF model and use it for this, but it doesnt seem to work very will with just using it for local data.
My question is- is there a correct usage of the EF for working with local data, and perhaps then just serialize/deserialize the whole context to a file? Or is this just too much effort to make work properyly? I used to use Datasets in this way, along with Linq to Dataset, and it works well... So perhaps those are still the better way to go for this scenario?
Yes you can use entity framework as local, and also access the data that is currently in-memory, read details as link below:
http://msdn.microsoft.com/en-us/data/jj592872.aspx
I don't know what you mean by "local data" exactly (sounds like it's not a database), but I think the Datasets vs. EF portion of your post is (for me) the real question.
EF is great when you need to model robust business logic, are implementing a Domain Model pattern, using Domain Driven Design, etc: basically any scenario where a Table Module or Active Record pattern is inappropriate.
When you just need to display some grids of data, and the business logic is very simple, Datasets are definitely the way to go (in my experience).
I recently started using RavenDb. I am converting a relational dbase to use RavenDb. I have two simple tables in the Relational dbase:
tbStates
tbCities
I have all US cities linked to a state. How can I go about converting this to no-sql. Will I have to write a little application to read from the relational dbase and create the objects? Or are there some tools out there I can use to do this?
There is a utility called smuger http://ravendb.net/documentation/smuggler but I imagine you will have to convert your data to Json. It may be just as easy to write a console app that reads the tables to objects then loads to Raven.
Just to add I migrated a SQL Server database to RavenDB using the console application route.
I used EF to quickly pull out the data and converted it to my RavenDB domain then added it to RavenDB.
It Worked well as you will most likely want to tweak the domain anyway to work best with RavenDB (For example I had an Images SQL table that I turned into a List on the document etc).
See Ayende's RacoonBlog project on github (https://github.com/ayende/RaccoonBlog) as he does something similar to move subtext data to RavenDB. RacoonBlog is the engine powering his blog and makes for good learning material about how to use RavenDB.
I'm researching Umbraco for use as a base in a large CMS project, however the project calls for the SQL Server 2008 database to store spatial data against content.
Being new to Umbraco I'm still reading through the documentation and slowly building up an idea of it's architecture. However so far it doesn't look like Umbraco supports the storage of spatial data.
There only appears to be four database datatype options: date, integer, ntext, nvarchar
Is it possible to store spatial data to the database?
Update: Futher research into how Umbraco works has showed me I was on the wrong track. It seems the way to do this is store the lat/long data in the data inside the usual XML format Umbraco uses.
Then to use the Spatial.net extensions that have been built on top of Lucene.net, rather than use the limited search capabilities Examine exposes.
However this is all still theoretical, I've just not been able to achieve this. If I do before someone answers this question, I'll post my findings here to help others.
You could take a look at how to make user controls (with Visual Studio) in Umbraco.
It is also possible the versatility in Umbraco 'Document Types' is enough for you.
It is possible to extend Umbraco in any sort of way to get the solution you want. I don't know how you want the spatial data to interact with your frontend - so it is difficult to provide a direct solution.
Although there are ways to store spatial data and perform queries against it using Spatial.net, it's not a very elegant solution.
Instead I've created an additional table in SQL Server 2008 with the geometry/geography datatype and a reference to the Umbraco content it's connected with.
I've then got a event hook which updates this whether content is added/updated/deleted.
I would like to begin work on an iPhone app that does little more than display a books content for reading. The book content is available online, and is fully open source, but I would like to make the content available locally. With apps that I have worked on previously, namely with iPhone OS 2.X, creating (or finding) an .sql database and then just making queries for data from within the app worked really well. With the advent of Core Data (which I am not that familiar with) the older sql method may not be ideal. So my question is: What is the best way for me to go from online web content to locally stored iPhone readable content? Regardless of which approach I take, I am going to need a db (right?), so should I get the brunt of it out of the way and start with importing the web content into a db with all of the correct tables and columns? I guess with this question, I am just looking for a point in the right direction. If there were any suggestions about the best method for me to get rolling on this, it would be greatly appreciated. Thanks!
Core Data is good if you have "objects" that you want to make persistent. In the case of having just a lot of data to read/write, plain old SQLite may be simpler.
Sorry that I can't give any more specific advice, but it comes down to how complicated your app's data model and object models are. I'd recommend looking at Core Data, but don't use it just because everybody tells you how cool it is.
If you go with Core Data, you won't define your own SQL database schema, so don't start down that path until you've made the decision.
I actually would go with the Core Data route. Core Data is just an API provided by Apple to manage persistent data no matter the data backend (wether it is a flat plist file, an XML file, or a full sqlite database file).
In the case of a book, you can break down the entities as follows.
Book Entity
Title which is a String Attribute
Author which is a String Attribute
chapters which is a has many relationship of Chapter Entities
Chapter Entity
Title which is a String Attribute
pages which is a has many relationship of Page Entities
Page Entity
PageText which is a String Attribute
Then you can access all the values as if they are objects using Core Data without having to worry about the SQL backend code, and writing all the code to translate the SQLite datatypes to Cocoa objects that your view controllers can display.