0

I'm trying to make an assembly which I can use in mutliple programs. The assembly contains a huge amount of countries and a huge amount of towns in that country. the data for countries is not much of a problem because I only count 249 countries but I also have huge amount of data for towns.

For example france has nearly 50.000 towns. Belgium has nearly 2500 towns. United kingdom nearly 150.000 towns. ...

I already have all the data I need but my problem is. I have no idea how to store the data in my assembly. - I tried XML but loading the xml give me performance issues. It takes to long to load the data. - I tried a MS Access database but then the data is store in a database outside my assembly while I try to keep the data inside my assembly. which means thats not my solution to. - I tried loading the data directly in an array in my script but then my visual studio keep loading all day long checking the data I entered but I can't work with it anymore

Anyone can give me a way to store data in my assembly without having these performance issues?

Any help is welcome.

I work with visual studio 2010 in the language C#

Davy Quyo
  • 102
  • 6
  • 7
    Why are you trying to "keep the data inside" your assembly? (you understand that it will still be trivial for a user to pull the data out of the assembly and thus you're not protecting the data in any way?) – Kirk Woll Feb 05 '13 at 19:00
  • 4
    Do you always need to load all the data? How large is the XML? How long is "too long"? – Jon Skeet Feb 05 '13 at 19:00
  • 2
    Any of the in-memory database such as SQLite? – shahkalpesh Feb 05 '13 at 19:02
  • 2
    Take a look at this question: [How can I embed a SQLite Database in a .NET DLL and then use it from C#](http://stackoverflow.com/questions/791198/how-can-i-embed-a-sqlite-database-in-a-net-dll-and-then-use-it-from-c) – psubsee2003 Feb 05 '13 at 19:06
  • The answer to "a way to store data in my assembly without having these performance issues" is - it is extremely unlikely that you can load 200K items (which at 1Kb per item give 200Mb of data) - without thinking about performance... – Alexei Levenkov Feb 05 '13 at 19:20
  • I want to keep the data inside my assembly because I only have to make a reference to that one assembly file then. I want to make it easier for myself this way. befor I can take the data I need I need to load the complete file. the xml from france alone is already 6.12MB large. It took for that file alone already 6 seconds to load the data in. I have no experiance with SQL Lite, so never tried that. Thx for the link. I look at it carefully and saw it dumbs the database somewhere to retrieve data from it. I could do that and then cach the data in my assembly but I'm really no fan of this. – Davy Quyo Feb 05 '13 at 19:22
  • But if you really insist to use a flat text file rather than a database, consider that the start and end tags can inflate the size of an XML file quickly. A custom file format or something that does not include start and end tags (like JSON) might be an alternative. But in the end, it won't save you much. A database like SQLite will be a far better option. – psubsee2003 Feb 05 '13 at 19:28

3 Answers3

0

If you are determined to hardcode it into an assembly you could go down the route of multiple Dll's containing each country.

They way if you only need to access the France file you can just create an instance of the France class and not the whole world.

CathalMF
  • 9,705
  • 6
  • 70
  • 106
-1

you may want to look at geo coding instead. i once used a dat file that had a bunch of US Zip Codes and that info in it. I am sure similar things exist elsewhere.

you may just want to look at google geo coding though.

mmeasor
  • 459
  • 3
  • 19
-1

It wouldnt be a very good idea to keep all that data inside your assembly. 1. It makes it very large. 2. It is difficult to update.

If you are worried about other people seeing the information in a database or xml document outside your assembly you should look into some basic encryption.

EDIT: 1. Having a very large assembly would be a poor idea due to having to load all that information into memory unnecessarly. This is assuming that the program does not need 100% of the information every time it runs.

CathalMF
  • 9,705
  • 6
  • 70
  • 106