I am looking to move away from neo4j mainly because of the price which is so steep and we assumed it to be an opensource all the time. Upward of $30K/year is not something we can afford for a database, I guess we should have done our homework well.
Any ways Neo4j has an actively maintained neo4jClient for .Net which was the primary criteria for us to select that database, only other option that comes close is OrientDB which also has a rest endpoint that we can consume. But has only few c# clients that I can find on the net. Also out of these none have been updated for almost 2-3 years.
So I was wondering if any one has used OrientDB in a real world project and have seen a dependable c# client that can be used with this database.
Also any sample that shows some of the best practices on working with OrientDB and ASP.Net will be really helpful.
Regards
Kiran
I am on the OrientDB Team. I have to apologize, we have not done a good job of communicating the various language APIs on our website. This will be improved.
For now, you can see: https://github.com/orientechnologies/orientdb/wiki/Programming-Language-Bindings.
I know I have seen activity around the .NET connector recently. We are have a concerted focus on all of these libraries and continued maintenance of them. Again, as you mentioned, the REST API is always there as well.
Best wishes,
Greg McCarvell
Orient Technologies
info#orientechnologies.com
The .NET driver I can suggest is:
https://github.com/workshare/OrientDB-NET.binary
It's actively updated.
I would like to create an EMR system. Any suggestion on what kind of database should I use and how to implement such? By the way im planning on using ASP.NET for the website. Thanks!
I worked for a medical company earlier and for EMR they used Sql Server but for HL7 it was Hadoop.
You can use any RDBMS, but it really depends on many factors.
I have three different applications, they all share the ASP.NET membership aspect of the database and almost definitely they won't share anything else.
Should I have a separate database for each of the applications, or would one suffice?
All the application tables are prefixed, so that wouldn't be a problem in integration. Although I was wondering if there would be any performance issues, or if having all three applications share the same database would be some kind of grave mistake.
The applications in question are three web applications, the "main site", a forum and a bug tracker. I'm wondering if this is viable because integration could be easier if I had a single database. For instance, the bug tracker registers asp.net membership tables in it's db connection, and it even creates an "admin" user, where the db that is actually supposed to be holding the membership tables would be the "main site" one.
Update: I added a bounty to this question since the answers seem to have pretty split opinions about whether I should or not use multiple databases for different applications that share only membership providers.
Separate apps = separate databases - unless you have to "squeeze" everything into a single DB (e.g. on a shared web hoster).
Separate databases can be backed up (and restored!) separately.
Separate databases can be distributed onto other servers when needed.
Separate databases can be tweaked individually.
I have always found it would be better to have more databases so that it is easier to:
Migrate to more servers if needed
Manage security / access easier
Easier (and Faster) restores and backups
I would actually go with four databases. A Membership database, and then one for each application (if the membership is truly shared). This will allow you to lock security across applications as well.
Looking at your question closer... You say that the data would "likely not be shared"... will a lot of your queries be joining tables with the membership? If so, might be easier if they are in the same database. However if you are going with a more entity based approach, I would think you would still be better with multiple databases. You might even want to look at something like an LDAP database or some other type of caching for your membership database to speed things up.
You should use the same database unless you have a current need to place them in separate databases - HOWEVER where possible you should architect your system so that you could move the data into a separate database should the need arise.
In practise this means that you should keep SQL procedures working the smallest amount of data possible - i.e. Don't have multi-step stored procs which do lots of separate actions. Have separate usps and call each from code.
Reasons to use separate databases:
1) Unrelated data - Group data that is interrelated - andonce databases get beyond a certain complexity, look to separate out blocks of related data into separate databases in order to simplify.
2) Data that is of either higher importance (e.g. Personal Details) should be separated to allow for greater security measures: e.g. screening this data from developers
3) or lower importance (e.g. Logging Info) - this probably does not need backing up - and if it's particularly volumous, you probably don't want it increasing the time taken to back up the main site database.
4) Used by applications living on different servers at different locations. Quite obviously you want to site data as close as possible to the consuming application.
Without really knowing the size and scale of your system, difficult to give full opinion, if it's just your own site, one db may work for now - if it's commercial then i'd have 4 dbs from the word go: Membership details, Forum, Bug Tracker and MainSite related stuff.
Thus in code you would have a Membership manager which only talks to the Membership db, A BugManager, A ForumManager and anything else will only talk to the MainSite db. I can't think of any reason you'd need any of these databases talking to each other.
Just my inclination: although the three apps might not share much (not yet, anyway: but what happens when a forum post wants to reference a bug report?), they all belong to the same "system," so to speak.
I would definitely put all of the tables in just one database.
In my opinion , it is better to split the database for increased flexibility, security, efficiency, and scalability.
In future if there is any addition of requirement (you never know) which is common to all the three applications , it might be a little difficult to maintain.
For example: User login /audit trace for your 3 applications.
It may sound like I'm wandering a bit, but have you taken into account another possibility, that is separating all the authentication/membership functionality into an application itself?
From your description it seems you may add another application in the future. It would start to look like a network of sites, much like 37signals web apps, Google web apps or MSN web apps.
And thus, you may go for a kind of Single-Sign-On / Connect service. This one single application may offer authentication methods via web-services or any other mechanisms, it will have its own DB for you to tweak, modify, backup and move without affecting the other apps. I myself have found this situation many times and thus I love how easy is to share your Google or Facebook login among applications.
Perhaps I'm seeing it from a little higher perspective than yours, sorry if it's the case. If this is not an option, you may keep 4 databases: 1 for each application and 1 for the membership provider, which has its own connectionstring most of the time.
Of course it depends on the size of your applications' footprint on DB-level. 10 tables per app is OK, 150 tables per app would make the DB a little ugly to us, that being a personal preference.
Good luck with whatever option you choose.
The membership framework allows for partitioning across multiple applications, so you probably should have the following configuration:
Membership Database
Application 1 Database
Application 2 Database
Application 3 Database
Then, in each of the application databases, create synonyms that point to the membership database's tables for when you need to write your own queries that access both application data and membership data. Synonyms are easy to maintain and allow you change where the database is without changing any dependencies on those tables as the synonym names don't change.
Your application configuration in Web.config will determine how the data is partitioned in the membership database as you specify an ApplicationName that should be different for each app.
I am deploying a desktop application using AIR, and I would like to store some user-specific data on the machine such as a history of his entries. Is this possible? Where can I learn more about this?
Thanks,
Mike
This blog tells what all options you have for local data storage using AIR. Select one which best fits your needs and livedocs(Adobe Help site) will contain a good explanation of them along with examples.
There are some examples in the Air version of Tour de Flex for how do this.
How would I programmatically connect to an existing back-end system of a restaurant using say Micros POS, with a web app built with .Net and C#. Thanks.
Update: Sorry for the ambiguity but I'd like to set up an online ordering system that takes users' orders and forward to a restaurant's back-end system to be processed and printed in the kitchen for cooks to see.
There is no particular reason for choosing .Net other than the fact I'm most familiar with it. I'm open to other options.
In general I'm looking for information regarding the feasibility of this and how to go about it programmatically. How would my app send orders to the kitchen's printers? Do restaurant back-end systems allow for a .Net (or any other) app communicate with it? Do they provide an API?
I currently work at an ISV that does basically this with another one of the big 3 point of sale systems.
First and foremost, get the Micros environment up in a VM.
Next, most of these back office systems are running either Windows 2000 or Windows XP (depending on the age of the system), so be really careful about the version of .Net you choose.
Now, as far as architecture goes, run a service on the back office that communicates regularly with a centralized web service (the website that customers order on), once an order is made available, from there you can then insert it into <insert pos type here>.
You will also find in most instances, especially with Micros being the largest Point of Sale on the market for restaurants, they will not be very helpful with documentation and helping you out with integrating into their software.
Also, I think that My Micros (their enterprise application) already supports this type of functionality.
Another opinion, get into FSTech this year and browse all the competition, there are tons for online ordering just so you can get familiar with the competitions feature sets.
What you need to know is define what you want to do with the POS before a choice of technology, if all you want to do is show some data/reports from the POS system's work, you would need to connect to whatever back-end database the POS devices feed into.
If you need to do something else, you need to look for whatever relevant documentation.
It would help you more to ask a more specific question.
I would probably start by determining if Micros POS has an API. If they do, are the systems at individual restaurants even connected to the net? Try chatting up the manager at a place that uses one of these systems, or just check the documentation on their website.