So, we want to move out from Air (Adobe stopping support and really bad implementation for the sqlite api, among other things).
I want to make 3 things:
Connect with a flash (not web) application to a local mysql database.
Connect with a falsh (not web) application to a remote mysql database.
Connect with a flash (web) application with a remote mysql database.
All of this can be done without any problem, however:
1 and 2 can be done (WITHOUT using a webserver) using for example this:
http://code.google.com/p/assql/
3 can be done using also the above one as far as I understand.
Question are:
if you can connect with socket wit mysql server, why use a web server (for example with php) to connect like a inter connectioN? why not connnect directly?
I have done this a lot of times, using AMFPHP for example, but wouldn't be faster going directly?
In the case of accessing local machine, it will be a more simple deploy application that only require the flash application + mysql server, not need to also instal a web server.
Is this assumption correct?
Thanks a lot in advance.
The necessity of separate layer of data access usually stems from the way people build applications, the layered architecture, the distribution of the workload etc. SQL server usually don't provide very robust API for user management, session management etc. so one would use an intermediate layer between the database and the client application so that that layer could handle the issues not related directly to storing the data. Security plays a significant role here too. There are other concerns as well, as, for example, some times you would like to close all access to the database for maintenance reasons, but if you don't have any intermediate layer to notify the user about your intention, you'd leave them wondering about whether your application is still alive. The data access layer can also do a lot of caching, actually saving your trips to the database, you would have to make from client (of course, the client can do that too, but ymmv).
However, in some simple cases, having an intermediate layer is an overhead. More yet, I'd say that if you can, do it without an intermediate layer - less code makes better programs, but all chances are for that you will find yourself needing that layer for one reason or another.
Because connecting remotely over the internet poses huge huge huge security problems. You should never deploy an application that connects over the internet to a database directly. That's why AIR and Flex doesn't have remote Mysql Drivers because they should never be used except for building development type tools. And, even if you did build a tool that could connect directly, any descent network admin is going to block access to the database from anywhere outside the DMZ and internal network.
First in order your your application to connect to the database the database port has to exposed to the world. That means I won't have to hack your application to get your data. I just need to hack your database, and I can cut you out of the problem entirely because you were stupid enough to leave your database port open to me.
Second most databases don't encrypt credentials or data traveling over the wire. While most databases support SSL connections most people don't turn it on because applications want super fast data access and they don't want to pay for SSL encryption overhead blah blah blah. Furthermore, most applications sit in the DMZ and their database is behind a firewall so between the server and the database is unlikely something could be eavesdropping on their conversation. However, if you connected directly from an AIR app to the database it would be very easy to insert myself in the middle and watch the traffic coming out of your database because your not using SSL.
There are a whole host of problems doing what you are suggesting around privacy and data integrity that you can't guarantee by allowing a RIA direct access to the database its using.
Then there are some smaller nagging issues like if you want to do modern features like publishing reports to a central server so users don't have to install your software to see them, sending out email, social features, web service integration, cloud storage, collaboration or real time messaging etc you don't get if you don't use a web application. Middleware also gives you control over your database so you can pool connections to handle larger load. Using a web application brings more to the table than just security.
Related
I wanna really know what is Client/Server in DBMS,in Hardware,Software and in Architectural point of view.
Whats the difference between Client/Server Technology and File Handling System.
A Client and a Server are two separate entities -- hardware and/or software. The Client asks a question; the Server sits around waiting for questions and provides answers.
The "separate entities" is to emphasize they are logically separate, even though you may put them on the same hardware.
In databases, the Client says "SELECT ..."; the Server says "here's the result set for that query". Or it might say "there are no database rows satisfying that query". Or the Client says "Please INSERT ..."; the Server says "OK, that's done". Note, in this latter example, the "result" is more of just an "acknowledgement".
A database Client may, but does not have to be, on a separate physical computer as the database Server.
The terms "client" and "server" correspond to roles in a communication by two (or more) software components(like father and son in a family relationship).
Usually the software-component that has the data and the logic of operating on that data is called the server, as it serves with data and activity. A software-component that connects to that server and communicates with it and has not all data and logic is called the client, which is usually quite passive. Server and client are not bound to hardware: You can have a HTTP-server on your working machine as well as a browser (a HTTP-client). In real life you apply separation of concerns also to hardware: You have big data-stores with high responsive hardware that you dedicate to the server-software-component and lots of smaller working machines that have a client-software-component to connect to the servers.
This concept can be applied to most software systems, like databases (server keeps data, client knows how to asks for data), documents (HTTP-servers have the documents, manage them and can even contain logic-components, like PHP scripts or applications, and usually browsers as clients). Server and client are not opposit. Having an application server, like a SAP system, the server is usually also client to other services. The application logic is usually seperated from the database, so the application, being a server for the application clients, is (or has) a client to the database.
As the client/server view is a hierarchical division of software communication, you can also have components with equal rights. Some distributed architectures have equal components that communicate with each other, having the same abilities und logic, and eventually having all or part of the data.
In a client-server separation of software both components can be on the same hardware, but they also can communicate via networks and be on different hardwares. Usually the server has the hard-working part so you can have a lot of lightweight clients that only send requests for currently needed data and logic.
But that all is not a must have. When a computer connects to another computer and copies all the logic (programms) and data from it, to become another server, in the process of copying all that information, the taking machine is the client and the giving machine the server.
I'm not sure, what you mean with "file handling systems". A file handling system is usually a software component to serve you data from a file system. Usually it is a local issue, the file system operates on the harddiscs on one hardware. But there are also distributed storages, like NAS (network area storage), where you also have client and server components connected through a network.
So to sum up, what the advantages of a client/server architecture are:
separation of concerns (this allows for specialisation)
independent scalability of the server and the clients
concentration of logic / data that works together (follows separation of concerns) this makes maintainance of the logic on the server much easier (imagine you would have to update all browsers to have a change in your application)
Hardware Component of a Client/Server System
It has mainly 3 types Client,Network and Database Server
Client may be PC's,Laptop,Moblie,Tablet.
Network is the Cabling,Communication Lines,NIC,Hub's,Routers,LAN,WAN.
Server is a computer which is having Enough Processing Speed,Internal RAM,Disk Storage etc.
Software Component of a Client/Server System
It has 2 type's Client and Database Server,Application Software is run on Client side,it uses data that Stored on Server via Sql Queries through data access API's like JDBC and ADO.net.
Architectural Component of a Client/Server System
It mainly uses 2 type Application Servers and Web Servers,Business component is stored in Application Server.Web Servers are used to store Web Application's and Web Service's.
I am developing an application which uses as a back-end an MS Access database (.mdb, not my decision). Recently I came across someone suggesting that using JET engine over WAN is not really a good idea, with a high risk of data corruption. Since my application should be doing just that (connecting to database on NAS (EDIT: not NAS, shared shared network drive), I got worried. It is really that risky? If so, is there any work around or is an MS Access database just unusable for that kind of application?
EDIT
The front end is .NET windows desktop application in C# (WPF). The system does not have many users, max 10. Most of the time they will approach the database from LAN and 99% of writing to the database will be done within the LAN (from the area of the company). However there are some cases where they will connect to the NAS (EDIT: not NAS, shared shared network drive) from outside the company via network (from their home).
If you have a 100 Mb/s fibre, it will be OK, but if your line is, say, an xDSL line, it is generally an absolute no-no.
Convince the powers that be to move the backend to a server engine like SQL Server where the Express version is free.
The scenario you describe is not a good fit for having an Access database as the back-end. The WAN users could very well find the application slow, but the NAS is the real cause for concern regarding corruption, and that would affect both LAN and WAN users.
Many (most?) NAS devices run on Linux and use Samba to provide Windows file-sharing services. The Access Database Engine apparently uses some low-level features of "real" Windows file sharing that Samba does not always fully implement (ref: here).
In fact, the only time I've seen repeated corruption problems with a shared Access back-end (and a properly distributed front-end) was when a client moved their file shares from an older Windows server to a newer NAS device. The Access application continued to work for the most part, but every few months they would find that the primary keys of some tables would disappear after they did a Compact and Repair on the back-end database file. That never happened while their file share was on the Windows server.
Splitting a front-end from a back-end removes the majority of the risk of corruption. Of course, with Access there's always the possibility and if you're looking for something that reduces the risk to close to nil then you might want to consider SQL Server or MySQL. However, using Access is fine as long as you take proper precautions.
For example, you might want to look into record-locking on tables that will get edited, to prevent multiple simultaneous writes. Backing up your DB on a regular basis is always good, too.
I am making a Javafx program and need to use a small mySQL database. Currently I am hosting one on my computer but I can't access it on other computers on other networks. I need the mySQL server to be accessible from anywhere. How do I host one that does that? Thanks in advance, all help is welcome.
Well you have a few options depending on how important this MySQL database is to you, how you intend to connect to it from outside, and what you want to do with it.
The naive implementation would involve opening your firewall and directing all incoming traffic using whatever port you have configured MySQL for to point to the ip address of your server. If you do this you absolutely must secure your database with a password!!! You'll also need to keep the server's public ip address handy so you know how to find it when you go out.
Use Amazon AWS, Google Compute, Google App Engine, or some other cloud platform to host a MySQL instance. All the big players also tend to host pretty awesome RDBMS solutions. The advantage here is that you're not exposing your home computer to malice and you are connecting into an ecosystem that will answer a lot of other questions for you as they come up along the way (IE - how do you ensure redundancy? Backups? Scale your network for traffic?). There's a ton of other advantages too. It's the cloud... dude...
Use a SaaS DB service such as Firebase (Note: We are leaving MySQL and SQL database territory with Firebase)
If you plan to let other parties access your MySQL instance to make use of your data, you might also want to consider implementing a REST API (or SOAP API if you hate the future) which acts as an abstraction layer to interact with and provide the data from your database in a consistent and reliable format.
Best answer I can give with the details afforded - look around though the options in this arena are near limitless depending on how and what you're trying to do.
You should be able to access your machine from your LAN pretty easily unless there is some firewall rules preventing opening connection to your machine. Another way is there are many cloud shosting providers has free tier you can signup to bring up a test instance of mysql. Example: Open Shift.
I have a broad question that I would like some advice on.
Currently, I have a number of databases in a shared location on our company's network. When at the office, these can be accessed quickly (but through VPN, it's slow).
We have multiple locations around the country and can access the drives of each location to pull up excel sheets, pdf's, etc. The problem is, Access applications are Extremely slow when accessing another location's shared drive.
Is there anything that can be done to increase performance other than migrating to SQL server and using a web-based app? Just looking for general advice here.
The reason why the VPN is slow is well because your VPN is likely 50 to 100 times slower than your LAN (local area network). In effect you asking the following question:
Why does it take longer to walk to the store then to drive to the store?
Answer:
because you going slower along the way (not really rocket science here).
A few solutions are:
Consider moving the back end data part to SQL server. So while ADP's are being depreciated, this in no way affects the great choice and suggestion to keep the Access application as a front end and move the tables (data) to SQL server.
If you only need a few forms, then Access 2010 (and 2013) does now support web publishing. Here is a video of an Access application of mine, and note how at half way point I switch to running the application in a standard browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
As noted, another great solution is to use some type of remote desktop solution. I explain why your connection is slow and give some suggestions for using Access on a WAN here:
http://www.kallal.ca//Wan/Wans.htm
So the basic issue here is your VPN is too slow and is far slower then your LAN.
You cannot increase performance over slow connections of an Access Database. There is no server serving records to the client, so Access has to download the whole dataset to do operations on it. You don't have to have a we-based app, though.
You can try to convert your .mdb to a .adp, or access data project. If successful, you will still use Access as the client, but all your data would be migrated to SQL Server. Queries on this data will be handled by the server, and you will see drastic performance improvements over slow connections.
I have been making some research in the domain of servers for a website I want to launch. I thought of a certain configuration of a server with RAID 10 implemented with a NAS doing the backup which has a RAID 10 configuration as well. This should keep data safe in 99.99+ of cases.
My problem appeared when I thought about the need of a second server. If I shall ever require more processing power and thus more storage for users, how can I connect a second server to my primary one and make them act as one what the database (mySQL) is regarded?
I mean, I don't want to replicate my first DB on the second server and load-balance the request - I want to use just one DB (maybe external) and let the servers use it both at the same time. Is this possible? And is the option of backing up mySQL data on a NAS viable?
The most common configuration (once scaling up from a single box) is to put the database on its own server. In many web applications, the database is the bottleneck (rather than the web server); so the first hardware scale-up step tends to be to put the DB on its own server.
This also allows you to put additional security between the database and web server - firewalls are common; different user accounts etc. are pretty much standard.
You can then add web servers to the load balancer, all talking to the same database, as long as your database can keep up.
Having more than one web server also helps with resilience - you can have a catastrophic hardware event on one webserver and the load balancer will direct the traffic to the remaining machines.
Scaling the database server performance is a whole different story - though typically you use very beefy machines for the database, and relative lightweights for the web servers.
To add resilience to the database layer, you can introduce clustering - this is a fairly complex thing to keep running, but protects you against catastrophic failure of a single machine.
Yes, you can back up MySQL to a NAS.