At first, I found a P2P CRM on http://www.ajatus.info/. But it was discontinued for years. And it is not natural to have a local web server. And the worst thing is that is hard to integrate its data with other data source for it used CouchDb.
So I draft a P2P CRM proposal and I am thinking to implement it.
Features:
Decentralization
Free( Free for software, no additional cost for related software)
Run Immediately (No installation needed, no configuration needed)
Social networking support.
Email and Contacts friendly
Basic architecture: 4 independent software.
1, Personal CRM
A Silverlight CRM application with a built- in SQL CE database. This is a completed package to run and no installation needed any more.
2, Central CRM
Central server is for performance and to simplify the support, which could be based on a typical SQL Server database of Splendid/Tiger CRM. This is a completed package also.
3, CRM Bridge
A bridge to synchronize the personal CRM and Central CRM. This will be an open source project for ANY CRM synchronize to the client. This is to be done by MS Sync Framework. ( MS Live Sync could be a better solution when it is ready and available in XP platform.)
4, Social Collector
A social data collector to collect all data from social networks and other data source. There is a good project in Codeplex.com (http://semsync.codeplex.com/) to collect and synchronize all contacts information together.
Scenario:
personal only.
Client to Central CRM directly (in DB layer).
Personal with synchronization to the central.
Any suggestions?
Ying
If Java is an option for you, the JXTA framework will help you with the P2P features of your application.
Sorry but I feel your base analysis is somewhat flawed.
"not natural to have a local web server"
By whose rules?
If you are a intenet application vendor (cloud computing hawkers) then they will tell you it is not natural.
The whole thing of P2P is to rethink those values.
If it makes sense put a web server on the localmachine put it on the local machine
Remember the original vision "The network is the computer";
Not "Large Data Centers are the computer"
2."CouchDB is hard to integrate"!
I think that is misinformed.
CouchDB has a RESTful JSON API that makes it about as integratable as you can get.
What you really mean is Couch doesn't fit into Visual Studio Development System like SQL Server. Which is true but doesn't make it hard to integrate data with other data.
There are some replication options you might want to look at.
To be honest what you are offering isn't much different than MS CRM with a social plugins module.
I think it would be difficult to get traction in the OSS Space and your gonna need help for a project that size.
Related
I'd like to understand more about what DB products/combos-of/platforms are generally used these days to build applications which have both mobile and web clients connected to a centralised DB. Lets just say, for example, I wanted to build a simple "To-do" List app which multiple users can download/use. With the following requirements:
Preferably built using free/open source/community products (understand hosting costs involved) but also happy to hear cloud-based options too (other than Firebase)
Must support both a mobile (ios/android) & web client (web app)
Central server-side DB (to support above) with sync capabilities to update clients (mobile/web), when an update takes place clients sync/update
Offline "read" capability (no offline write necessary)
NoSQL/Doc DB is fine (RDBMS would work too though)
This exercise is to help me (and others interested) understand the options/products/platforms available when attempting to create an application with such requirements. Its intrigued me for a while what options are available for a non-enterprise, non-commercial application such as a to-do list where a users data is sync'd across devices yet available to a web client too, via an architecture that doesn't come with enterprise costs.
I've looked at various offerings from the main vendors but when it comes to synchronising data between devices and a central server DB, generally paid-for products are required. I see free apps daily which must use highly cost-effective (bordering free) components (above basic hosting) in their architectures and just wonder what products they generally use to achieve apps capable of synchronising data between clients from a centralised DB/server.
Need a easy to set-up and flexible web front-end for a data warehouse built in SQL Server 2008. I'd like to be able to expose both SSRS reports and SSAS cubes for browsing.
Seems like Microsoft wants us all to use Sharepoint for this, but I want something I can expose to internal users as well as customers, so I don't think Sharepoint will work (right?).
The other big approach people take seems to be coding up a custom ASP.NET app, which I have no desire to do.
Basically just want something like Cognos or Business Objects, but as a front end to SSRS and SSAS, not some proprietary data structure.
Why is this so hard to find - seems like it would be a common need. Why doesn't Microsoft make this?
Only one I've found so far is Report Portal (www.reportportal.com), which seems pretty good, but not stellar. As far as the big guys go, it looks like MicroStrategy (microstrategy.com) can work with native SSAS cubes, but for general reporting has it's own structures. Graphs and interface look good though, so would appreciate hearing from anyone with experience integrating Microstrategy and SQL Server as well.
Thanks!
The Enterprise version of SharePoint does what you want and more. It is also able to handle external users, but that requires some serious thought to architecture etc. However Enterprise SharePoint is not cheap, nor is a SharePoint farm installation a minor exercise.
Having used SharePoint to do this, it is very powerful, but does not work well over SSL, so terminate your SSL at the F5 or other hardware.
For information on planning a SharePoint implementation, have a look at
Planning an architecture for SharePoint server 2010
also Extranet topologies for SharePoint 2010 Products
Running through the rather large amount of documentation here should give you a glimpse of what is involved in getting a SharePoint extranet working.
Would be really interested in a good "non-sharepoint, non-BI" answer. I see this question asked all over the place with people specifically saying "I don't want to use sharepoint, what are the alternatives." and invariably the next 200 answers are "Use sharepoint"
If you're a SQL/Asp shop that just does standard web, sharepoint and BI are both megatons of bloat just to get internet/intranet report delivery.
So the answer is "No there's not a "Front end in a box" other than the ones you've mentioned. Go kickstarter one as this is one of the most frequent searched on pain-points I've ever seen with the least amount of viable answers/solutions.
What are the strategies you employ to let multiple people work on an access database?
Is it possible to host it online and have its features still functional without having to develop a custom frontend?
MS Access as a software has a few nice features that don't require any programming to configure:
Drop down lists - choose one
Multi Checkbox lists - choose multiple
Is it possible to get all of these features available even when hosted online? I'm basically thinking of an alternate way to quickly get people to work with data using GUI features like the above without going the webapp<>MySQL way.
You have some good comments here. Keep in mind that things have changed quite a bit for access 2010.
Access 2010 allows you to build web applications. The development process is very much the same as it’s been for years, but you can’t use VBA in forms for these web applications (you use a new macro language). This new feature set allows you to publish applications you build to a website. Here is an video of an application of mine running in access 2010, and at the halfway point in the video I switch to running the access application 100% in a web browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
The above is for access 2010…due out this year. The above will require you to be running SharePoint services, or use an hosting service that supports "access web" services.
For previous versions of access, for all intents and purposes, it’s not a web based system at all. Now when you say multiple users, you have to clarify what kind of users and where they plan to be. If your users are on a local office network, then MS access can be used as a multi user system right out of a box with no additional coding and programming required. It is recommended however that you split your application into a front end part that’s deployed on each user’s computer. This Concept as outlined in the following article of mine.
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
Now, perhaps the users are going to be on notebooks and in different locations all over the country? In this type of case you are attempting to connect over a wide area network, or have users connect to the application over the Internet. This is a different problem. In this type of scenario, a good solution is to use something like SQL server for the backend, and you continue to deploy the Access front ends to each user’s computer. This application tends to be about the most cost affordable also. And using sql server + ms-access means you get to continue developing in Access for the most part like you always done. Another way to accomplish wide area use without resorting to sql server is to use something called terminal services. I outline these possibilities in the following article:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
As mentioned, a few others here posted links to some of the new SharePoint features that you can consider using, but they not out untill later this year.
Multi-user Access apps are pretty easy to do for small workgroup user populations in the 15-25 ranger or smaller. Above that, a developer should consider upsizing to a server back end, with the trade-off being greater administrative overhead for the server vs. having to program the app more carefully if you retain the Jet/ACE back end.
As to online access, you this isn't possible over HTTP, but if you have a Windows Terminal Server available, you can host your app there and give users access to that. This is actually an extremely easy and efficient and inexpensive way to support remote users of an app, though the larger the user population, the more problematic it becomes. But by the time an Access app has a user population that would strain a Windows Terminal Server setup, you're no longer going to be using a Jet/ACE back end.
And with a server back end, you could give access to a SQL Server on a VPN over the Internet, and if you write your Access app really efficiently, even over a standard broadband connection, your users could still work productively.
Then there's the future of Access: in Access 2010, a great deal of work has been done to integrate with a host of new features in Sharepoint 2010. If you create your A2010 app using the new type of Access web forms and reports, your app can be uploaded to a Sharepoint server running the new Access Services, and it can then be used running in a web browser (not limited to IE and not dependent on any plugins or web controls, as was the case in the past with the completely worthless Access Data Access Pages). The data store can either be a SQL Server, or you could keep it Jet/ACE for users not accessing it via the web browser, and have the data stored in Sharepoint for the online users. Also, you can have an app integrated with Sharepoint running locally in Access that uses Sharepoint when connected to the Internet, and still be able to work offline when disconnected. When connected again, you synch your local changes with the Sharepoint server, resolve any differences and continue working.
The features are really quite remarkable, and according to what I've heard and seen, if the Access app is built entirely of web forms and reports, it will look and function identically when run in Access and when run in the web browser via Sharepoint. And if you need to have client-side features that you don't expose to the users running the app in the browser, you can still use traditional Access objects!
The Access development team's blog has a number of posts on what's coming in A2010, and there's a good video posted there demonstrating how A2010 integrates with Sharepoint 2010's new Access Services.
This constitutes a quantum leap in Access's web capabilities, which were previously almost non-existent, and I'm quite excited about this. I was formerly quite wary of the changes being made to Access that seemed entirely to make it a servant of Sharepoint, but now I can see that the benefit to Access users and Access developers will be huge.
One way i've heard of, is to import the access database into a SQL Server database.
(Almost any version will do.).
Then link to the SQL Server database with Access and let users use it as they did before.
Look at this link: http://office.microsoft.com/en-us/access/HA010345991033.aspx
If you want an online solution i'd recommend going with a normal web application architecture. (Talking to a proper database.).
I have never needed to support it myself, but from what I heard so far, performance dramatically breaks down as soon as you need to support multiple users writing simultaneously. I think this is because Access uses simple file locking to implement isolation, and this just is not the right technique for a concurrent database system.
Hosted on-line? Do you mean on the network? Technically it will work on a network but there is a reason MS-Access in not in Visual Studio - it is not considered a development platform - it is a desktop application. When MS-Access first hit the scene many people built applications using it. The multiuser functionality just is not there. Upto four or five users is ok. But I would not go for more.
I'm hoping you can help.
I'm looking for a zero config multi-user datbase that my winforms application can easily upload to a webserver folder (together with 1 or 2 classic asp pages) and am looking for some suggestions/recommendations.
The idea is that the database will be used to collect feedback entered by people filling in the asp pages. The pages will write to the database using javascript.
The database will subsequently be downloaded again for processing once the responses are in.
In Summary:
It will mostly run in MS Windows environments.
I have a modest budget for this and do not mind paying for such a database.
No runtime licensing costs.
Should be xcopy - Once uploaded to a website folder it should be operational.
It should not have a dotnet CLR dependency.
It should support a resonable level of concurrent access. Average respondent count would be around 20-30 but one never knows.
Should be a reasonable size so that uploads/downloads to and from the site will be reasonably fast.
Would appreciate your suggestions/comments
Many thanks
Abz
To clarify - this is a desktop commercial application for feedback management in a vertical market. It uses SQL Server as the backing store.
The application currently provides feedback management from email and paper feedback. I now want to add web feedback capability. Getting users to to make their SQL servers accessible to a website is not at option at this time as I am want to make getting up and running as painless as possible.
I intend to release a web based implementation of the software in the near future but for now am looking at the above as a pragmatic way to provide web based feedback collection.
SQLite comes to mind. It meets all of your stated requirements, is open source, and has a liberal license (public domain).
http://sqlite.org/
I would use 'normal' database (say MySql, Postgresql, Firebird, etc.) on server. Instead of copying files to server your winforms application would create custom tables (or even custom databases). After collecting data you could just get it back to your application using plain old SQL.
why reinvent the wheel ? If you want to collect feedback and stuffs from users of your app and if they are connected to internet, it might be a better idea - and in the long term cheaper - to use a service like wufoo. We recently switched from homegrown setup to wufoo and are very pleased. Check it out.
Otherwise you might want to take a look at sqlite orfirebird. Both of them are very robust, and have ADO.NET providers. Firebird scales from a single user to full blown client server system and has no .NET dependency.
If you really don't want a DB/SQL Solution, you could try simple text files and ftp/xcopy files down and parse them into the back-office server as needed. ASP/VBScript or ASP.NET can create the files to store the basic feedback comments. Need to consider security of course!
I was looking into the possibility of using CouchDB. I heard that it was similar to Lotus Notes which everyone loves to hate. Is this true?
Development of Lotus Notes began over 20 years ago, with version 1 released in 1989. It was developed by Ray Ozzie, currently Chief Software Architect for Microsoft.
Lotus Notes (the client) and Domino (the server) have been around for a long time and are mature well featured products. It has:
A full client server stack with rapid application design and deployment of document oriented databases.
A full public key infrastructure for security and encryption.
A robust replication model and active active clustering across heterogeneous platforms (someone once showed a domino cluster with an xbox and a huge AIX server).
A built in native directory for managing users that can also be accessed over LDAP.
A built in native mail system that can scale to manage millions of users with multi GB mail files, with live server access or replicated locally for off-line access. This can interface with standard internet mail through SMTP and also has POP and IMAP access built in. The mail infrastructure is a core feature that is available to all applications built on Notes Domino (any document in a database can be mailed to any other database with a simple doc.send() command).
A built in HTTP stack that allows server hosted databases to be accessed over the web.
A host of integration options for accessing, transferring and interoperating with RDBMS and ERP systems, with a closely coupled integration with DB2 available allowing Notes databases to be backed by a relational store where desired.
Backwards compatibility has always been a strong feature of Notes Domino and it is not uncommon to find databases that were developed for version 3 running flawlessly in the most up to date versions. IBM puts a huge amount of effort into this and it has a large bearing on how the product currently operates.
-
CouchDB was created by Damien Katz, starting development in 2004. He had previously worked for IBM on Notes Domino, developing templates and eventually completely rewriting one of the core features, the formula engine, for ND6.
CouchDB shares a basic concept of a document oriented database with views that Notes Domino has.
In this model "documents" are just arbitrary collections of values that are stored some how. In CouchDB the documents are JSON objects of arbitrary complexity. In Notes the values are simple name value pairs, where the values can be strings, numbers, dates or arrays of those.
Views are indexes of the documents in the database, displaying certain value, calculating others and excluding undesired docs. Once the index is build they are incrementally updated when any document in the database changes (created updated or deleted).
In CouchDB views are build by running a mapping function on each document in the database. The mapping function calls an emit method with a JSON object for every index entry it wants to create for the given document. This JSON object can be arbitrarily complex. CouchDB can then run a second reducing function on the mapped index of the view.
In Notes Domino views are built by running a select function (written in Notes Domino formula language) on each document in the database. The select function simply defines if the document should be in the view or not. Notes Domino view design also defines a number of columns for the view. Each column has a formula that is run against the selected document to determine the value for that column.
CouchDB is able to produce much more sophisticated view indexes than Notes Domino can.
CouchDB also has a replication system.
-
Summary ( TL;DR ) : CouchDB is brand new software that is developing a core that has a similar conceptual but far more sophisticated design to that used in Lotus Notes Domino. Lotus Notes Domino is a mature fully featured product that is capable of being deployed today. CouchDB is starting from scratch, building a solid foundation for future feature development. Lotus Notes Domino is continuing to develop new features, but is doing so on a 20 year old platform that strives to maintain backwards compatibility. There are features in Notes Domino that you might wish were in CouchDB, but there are also features in Notes Domino that are anachronistic in today's world.
It is the Notes application and UI that people usually hates. Not the architecture behind.
Damien Katz worked at Iris (Lotus), but he was not the guy behind the Notes Database. He is well-known in the Lotus Notes community for redesigning the Notes Formula Engine.
There are definitely some similarities between CouchDB and Lotus Notes, such as their document-oriented, non-relational data, and replication capabilities, but they are more disparate than similar. CouchDB is a database server and Lotus Notes is an enterprise-level collaboration platform.
#Lex, You should prehaps say what version of Notes/Domino you are working on because your comments are incorrect.
"No transaction support" - Domino has transactional logging. If you want more complex transaction logging that is also available within coding.
"not well suited for handling multiple data transactions" - Actually it handles them just fine. You have document locking and replication conflict resolution. Depends a lot on how you set up your application to handle workflow.
"No separation between production/dev environments." - False. The only way this could be true is if you had a badly deployed environment. Developers normally should have 0 access to deploy design changes to the production environment. They would work off a template which does not replicate to main servers. Once updates are done and approved then the administrator deploys it. They do this by taking the template and signing it with a controlled signature allowed to run on production, then drop the template in and update the design of the related applications.
"The more data lotus notes contains, the more views will likely get created" - This comment makes absolutly no sense what-so-ever. I don't believe you have used Notes/Domino in any professional ability.
"lotus script is not object oriented" - Yes you make good points there. However it doesn't mean that the language is flawed. Also they have made a large number of improvements since 8.x and with 8.5.1. For example built in web services support (point to WSDL and LS code is made for you). 8.5.1 Also has a lot of new designer features like Code Templates, auto-completion, LSDoc popup help on your own functions, etc.
You also only touch on LotusScript. Yet you can also code in:
Java, SSJS/DOJO (XPages), Javascript, #Formula language, Web Services (SOAP/REST), C-API, Eclipse Plugins(RCP). Output in JSON as well as XML.
8.5.1 Designer client is now free to download if you want to test it out.
So while I believe I am not in a position to comment on CouchDb you most certainly are not on Notes/Domino.
Lotus Notes client/Domino server is comprised of an object("document")-storage (not relational) mechanism, has fully integrated certificate-based security model / user management and conflict-resolution for syncing offline/online changes to data - it's a platform for distributed applications.
"CouchDB is a document-oriented, Non-Relational Database Management Server (NRDBMS)."
CouchDB is accessible via a REST style API.
There's a podcast interview with Jan Lehnardt of the CouchDB team here.
Without going back and listening to it again, I believe that Damien Katz, who was the initiator and is still the lead developer on CouchDB was also the guy behind the Notes database. So there's a sense in which CouchDB is a better Notes DB, I guess. He explains some of the differences in his blog.
It's similar to how Notes deals with data in that everything is a document of arbitrary structure, and you have views over those documents instead of tables and records like you'd have in a relational database. The replication etc also has some similarities.
There isn't anything wrong with the Notes server architecture, people don't hate that so much. It's more the implementation and bloat that comes with Notes.
CouchDB has no front end either, just a server component. The Notes client sucks, and that is what people REALLY hate. Have you ever tried to email uh I mean "memo" something from Notes? Not pleasant :(
Comparing Apples & Oranges
Lotus Notes Domino hasn't changed much and there is not a NoSQL service option on-prem or cloud for Notes Domino v12 or any earlier version. Domino is not cloud based tech.
When it comes to NoSQL, Domino uses NoSQL for its own application solutions built in Domino. There was an attempt with Domino Access Services which is based on Java 6, Rest API still uses Vectors in v12. This service is ok, not robust, it provided a way to interface with data in a NSF. Remember, Domino is key value pairs storage and very slow on large data sets because of the security model, each document is checked for readers and authors with every search to identify if the document can be viewed by the user. Domino is still Web 1.0.
With CouchDB one can build app on mobile and deploy it. There is no way to do the same with Notes/Domino because of the Domino Server. Domino dev also only supports MS Windows and the IDE is based on older versions of Eclipse, to this day v12, there is no way to use dual monitors with the Domino IDE. Ask any Domino Developer, they hate being forced to use a IDE on a specific platform that cannot keep up with industry.
Couch has gone through many changes as well, brief history:
CouchDB started by Damian Katz, IBM Lotus Domino engineer
Apache project BigCouch is born ; scalability and clustering added
Cloudant is born ; BigData and IBM funding and IBM Cloud offering
CouchDB 2.0 is born; Cloudant + BigData merged back into CouchDB
CouchDB 3.0 is born; Enhanced security and prep for Foundation DB
CouchDB 4.0 is born; architecture changed to Apples Foundation DB
https://www.dataengineeringpodcast.com/couchdb-document-database-episode-124/