As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I come to you after a desperate disappointing search online for an answer to my question:
Which one is faster: LDAP or Relational Database?
I need to setup a system with both authentication and authorization of users.
I know LDAP has the "structure" for that kind of need, but is it really faster than, say, MySQL?
For authentication and authorization purposes, in my opinion LDAP provides the best mix between performance and simplicity or installation and maintenance. LDAP as a protocol is quite small, requiring relatively little network bandwidth. The small protocol also makes encrypted transmission fairly high-performance.
LDAP is also simple, servers are easy to deploy, and modern, professional-quality LDAP servers provide impressive performance vs. relational database, all other things being equal such as hardware and query type.
I agree that either could be used in your case, but generally LDAP is better for authentication and authorization because of its simplicity and lower maintenance costs. As for performance, the LDAP server with which I am testing provides about 28,000 authentications per second vs. postgres providing about 42% of that number on the same hardware, though it is difficult to compare apples and oranges.
Modern professional-quality LDAP servers also provide extremely powerful and fast cryptographic hashes for secure password storage - as well as reasonably strong reversible block ciphers like AES in the event a reversible password is required if the client must SASL's DIGEST-MD5 mechanism for password-less authentication.
I agree with Al, it is impossible to say generally which is faster. It's all contextual.
I love that after this truism, Al then offers up a general opinion that LDAP is slow. :) I digress...
Joking aside, it comes down to what you're trying to do vs. what the target system is optimized to do. MySQL/MSFT SQL Server/etc. are built as general purpose stores where you will (tend) to store normalized data with a variety of query patterns over the data. They have all sorts of logic at many layers of the stack to try and help you do a variety of types of queries & computations over your data, and even let you hint things in to the QP when you know best.
LDAP directories tend to be optimized quite differently...like for the storage of hierarchically organized objects with a specific set of query patterns over it (as specified by LDAP RFCs). AD for example is fast...quite fast. It's optimized for object search & retrieval and associated operations (like auth).
Like anything, you can use either well or poorly.
Short of being in a crazy scale mode, I suspect you could use either quite successfully.
IMO this is not a real question, because it always depends on particular implementations.
I can put here only my experience: LDAP is slow, SQL is fast. I use MS SQL 2008 and in my case it is very fast thanks to its intelligent caching of repeated queries.
But do you need it to be exceptionally fast? LDAP-based solution can often offer easier and better integration to other software and/or LAN infrastructure when working with users, authorization and authentication.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a bunch of C code accessing database (Oracle, DB2 and Sybase) through Embedded SQL : the base code is the same, but with three different precompilers, three sort of executables are built, one for each database/platform.
I works perfectly fine, but we need now migrate to a solution using ODBC access.
The problem is : what tools / api can be used ? A direct way seems to write a custom precompiler (or modify an existent) to wrap all SQL and host variables calls to calls on an ODBC connection.
Can somebody recommend tools for that task or api to keep it simple ?
Or is it a simpler way, another approach ?
Thank you
As is usual for such situations, there are likely no off shelf answers; people's codebases always have a number of surprise in them, and the combination prevents a COTs tool from ever being economical for individual situations.
What you want is a program transformation system (PTS), with a C front end, that can be customized to parse embedded SQL. Such tools can apply source-to-source rewrite rules ("if you see this pattern, then replace it by that pattern") to solve the problem.
These tools require some pretty technical effort to configure. In your case, you'd have to adjust a C front end to handle embedded SQL; that's typically not in C parsers. (How is it that you can process this stuff in its current form?) You'll have trouble with the C preprocessor, because people do abusive things with it that really violate a parsers nested-structures-view of the universe. Then you'll have to write and test the rules.
This effort is a sunk cost to be traded against the effort of doing the work by hand or some more ad hoc scripting (e.g., Perl) that partially does the job leaving you to clean it up. Our experience is that it is not worth the trouble below 100K SLOC, and that you have no chance of manual/ad hoc remediation above 1M SLOC, and in between your mileage will vary.
At these intermediate sizes, you can agonize over the tradeoffs; that costs energy and time, too. Sometimes its just better to bite the bullet and do it any way you can an clean it up.
Our DMS Software Reengineering Toolkit is one of these PTS. It has a customizable C parser and preprocessor, precisely to help deal with these configuration troubles. The other PTSs mentioned in the Wikipedia article, do not, I beleive, have any serious C parser associated with them. (I'm the guy behind DMS).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How can I best write an application that sits in front of a generic SQL database (SQL Server, MySQL, Oracle, etc.) and listens to SQL queries?
The application needs to be able to intercept (prevent passing to the SQL database) or pass (send to SQL database) the query, based on the specific query type.
Is there a way to do this generically so that it is not tied to a specific database backend?
The basic system isn't particularly easy, though neither is it incredibly difficult. You create a daemon that listens on a port (or a set of ports) for connection attempts. It accepts those connections, then establishes its own connection to the DBMS, forming a man-in-the-middle relay/interception point. The major issues are in how to configure things so that:
the clients connect to your Generic SQL Listener (GSL) instead of the DBMS's own listener, and
the GSL knows how to connect to the DBMS's listener (IP address and port number).
You can still run into issues, though. Most notably, if the GSL is on the same machine as the DBMS listener, then when the GSL connects to the DBMS, it looks to the DBMS like a local connection instead of a remote connection. If the GSL is on a different machine, then it looks like all connections are coming from the machine where the GSL is running.
Additionally, if the information is being sent encrypted, then your GSL can only intercept encrypted communications. If the encryption is any good, you won't be able to log it. You may be able to handle Diffie-Hellman exchanges, but you need to know what the hell you're up to, and what the DBMS you're intercepting is up to — and you probably need to get buy-in from the clients that they'll go through your middleman system. Of course, if the 'clients' are web servers under your control, you can deal with all this.
The details of the connection tend to be straight-forward enough as long as your code is simply transmitting and logging the queries. Each DBMS has its own protocol for how SQL requests are handled, and to intercept and modify or reject operations will require understanding of the each DBMS's protocol.
There are commercial products that do this sort of thing. I work for IBM and know that IBM's Guardium products include those abilities for a number of DBMS (including, I believe, all those mentioned above — if there's an issue, it is likely to be MySQL that is least supported). Handling encrypted communications is still tricky, even for systems like Guardium.
I've got a daemon which runs on Unix that is adapted to one specific DBMS. It handles much of this — but doesn't attempt to interfere with encrypted communication; it simply records what the two end parties say to each other. Contact me if you want the code — see my profile. Many parts would probably be reusable with other DBMS; other parts are completely peculiar to the specific DBMS it was designed for.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been working on my own ssl based multi process multi file descriptor threaded server for a few weeks now, needless to say it can handle a good amount of punishment. I am writing it in C++ in an object oriented manner and it is nearly finished with signal handling (atomic access included) and exception / errno.h handled.
The goal is to use the server to make multi-player applications and games for Android/iOS. I am actually very close to the completion, but it recently occurred to me that I can just use Apache to accomplish that.
I tried doing some research but couldn't find anything so perhaps someone can help me decide weather I should finish my server and use that or use apache or whatever. What are the advantages and disadvantages of apache vs your own server?
Thank you to those who are willing to participate in this discussion!
We would need more details about what you intend to accomplish but I would go with Apache in any case if it matches your needs:
it is battle tested for all kind of cases and loads
you can benefit from all the available modules (see http://httpd.apache.org/docs/2.0/mod/)
you can benefit from regular security patches
you don't have to maintain it yourself!
Hope this helps!
You can always write your own software even when perfectly well-proven alternatives exists, but you should be conscious about what are your reasons for doing so, and what are the costs.
For instance, your reasons could be:
Existing software too slow/high latency/difficult to synchronize
Existing software not extensible for my purpose
Your needs don't overlap with the architecture imposed by the software - for instance if you need a P2P network, then a client/server-based HTTP protocol is not your best
You just want to have fun exploring low-level protocols
I believe none of the above except possibly the last of these apply to your case, but you have not provided much details, so my apologies if I am wrong.
The costs could be:
Your architecture might get muddled - for instance you can fall into the trap of having your server being too busy calculating if a gunshot hits the enemy, when 10 clients are trying to initiate a TCP connection, or a buffer overflow in your persistent storage routine takes down the whole server
You spend time on lower level stuff when you should dealing with your game engine
Security is hard to get right, it takes many man-years of intrusion testing and formal proofs (even if you are using openSSL)
Making your own protocol means making your own bugs
Your own protocol means you have to make your own debuggers (for instance you can't test using curl or trace using HTTP proxies)
You have to solve many of the issues that have already been solved for the existing solution. For instance caching, authentication, redirection, logging, multi-node scaling, resource allocation, proxies
For your own stuff you can only ask yourself for help
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am going to change my working sphere from Enterprise Web Applications written for concrete business process to Public Web Sites that will be accessible to all users around.
What is difference between this two spheres at the most top level? What specific characters I need to know about modern web sites development?
I suspect one could write books about this.
I suppose the first difference is the user base. With an enterprise, you can, at least partly, ensure the users are doing what they are supposed to - and if not you know who they are and where they live. Further, they can be fired for abuse. On a public web site, you almost have to assume that some part of your user base is not there for a positive reason. So be paranoid - if they're not attacking you yet, just wait.
A second related point is that users will find ways to use (abuse?) your site you never thought of. Plan for the worst, hope for better.
Third, language, culture and usage varies across the world. A form, for example, with "zip code" that accepts just 5 digits may make sense in the US but is useless in the UK. And asking for a state and restricting it to two characters likewise makes no sense say in Italy where Italy IS the "state". This also applies to actual content - that joke you think is so very funny may be offensive in other countries. And never under estimate the ability of some folks to be offended at anything.
Fourth - get a good bunch of beta tester and test your site, and updates, carefully and thoroughly.
Fith, have a plan for scalability - if you suddenly get "discovered" can your site take the traffic.
That's 5 things at least.
In an enterprise application, functionality and efficiency trump aesthetics every time. This is because you have a captive audience. The people who use your application are being paid to use it.
However, when opening an application up to the public, aesthetics becomes more important. There are always alternatives, and a given person will be more attracted to the application which looks better. Granted, functionality is still very important for repeat users, but you won't get people in the door if your application looks amateurish.
Browser agnosticism - In enterprise apps, it used to be that the developer would target the app at a specific browser, just for simplicity's sake.
In internet accessible apps, the developer must target the vast majority of browsers. While this has gotten easier in the last few years, it is still a issue that needs attention.
Scalability - its easier to scale an enterprise app, its easier to predict the growth of usage of the app, or simply design for access by all users in the org at once. This is not generally the case for internet sites. The day you get slashdotted, or dugg is the day that you learn this. Better to design scalability in from the start, rather than have to learn it at the time that your site starts to suffer.
In addition to Zack's answer, I would say that a web site/application that is open to the public needs to be constantly evolving/refreshed in order to grow your user base and keep them. Whereas on a more closed system, consistency and reliability are key priorities.
Depending on the nature of the application, if it has significant amounts of content Internationalization and presentation of content are hugely important.
As Zack mentions, public users have a lot less tolerance for poor UI than enterprise customers do. That said, public users are more tolerant of incremental change; you can upgrade a live site as you feel like it (as long as it works, of course!!) without having to go through endless feature-request prioritization committees and user-training requirements.
Public web sites needs to be easy to use. While it's important that they look somewhat polished, don't ever let polish get in the way of ease of use. For example many designers like fixed width layouts because they are more predictable, many users like fluid width layouts because they use the space more efficiently. Side with your users.
Enterprise users can be forced to deal with needlessly-complex systems (lord knows I am more than I'd like), the general public cannot.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
After reading Wolfbyte's answer on Enterprise FizzBuzz I have thought about what constitutes a program as "Enterprise".
What makes an application or a software development process as Enterprise?
EDIT: It seems like there is a lot of negativity around the word Enterprise.
Are there anyone who actually enjoys writing Enterprise-Level applications?
What "enterprise-level" really means is:
Compatibility with architectural schemes and long-term technical plans that overarch anything you or your team will ever do, and thus cannot be changed.
Conforms to governance requirements
Expensive to build and maintain ;)
Has the following qualities:
Maintainability
Scalability
Functionality
Reusablility
Reliability
Understandability
Usability
Modifiability
Testability
Portability
Efficiency
Flexibility
Modularity
Interoperability
As far as "enjoying" writing Enterprise-level apps, it can be difficult to do so because one of the characteristics of an enterprise system is that it's larger than any one person. People usually enjoy their work because they can take ownership of it, but enterprise development isn't really "owned" in that sense, rather it's "produced" through a rigid, complex project path guided by acceptance gates and steering committees and business project owners.
Think about all the things that you, as a programmer, care about in a software product.
Now think about all the things that you, as a user, care about in a software product.
Now forget about all of those things. Enterprise software isn't purchased by users or programmers. Requirements like "intuitive", "fast", or "interoperable" just don't apply.
Instead, they must meet requirements such as, "vendor published big fat whitepaper full of words like 'fast', 'intuitive', and 'interoperable', so when the peons complain that it makes their jobs more difficult we have something to point at while writing 'difficult' into their employee records".
Slow. Hard to use. Expensive. Based on obsolete technology. See the rails plugin "acts_as_enterprisey"
I kid.
Seriously though, it generally refers to things written for use by Fortune-1000 types, where there are large numbers of users and complex business rules.
If you're an ordinary developer, it's anything bigger than what you're working on now.
If you're an architect, it's the stuff you did at the last client.
If you're the CIO, it's all the stuff that "really matters" -- the stuff above baseline, keep-the-lights-on operations.
If you're in sales, it's what you're bidding on.
If it's your product, of course it's enterprise-ready. You just spent a year making it "scalable" so it would grow to support "the enterprise".
If it's open source, of course it can't be enterprise-scale. Nor, for that matter, is your competitor's product.
And, of course, it varies by client. For the $1B per year companies, a few Oracle financial reports was an Enterprise Initiative. For a Fortune 100 company, almost nothing is really "enterprise" because the entire enterprise is so big and globe-spanning that it's hard to comprehend any one thing that actually fits all the nooks and crannies of that conglomerate business.
Usually Enterprise is used in the negative. "Your software/service/product/offering isn't enterprise ready" or "Open source isn't suitable for enterprise computing".
An Enterprise Application usually something that has multiple tiers and runs on many machines and is designed to fulfill the needs of an larger organization. In practice it usually has a database backend, business logic middle tier, and some kind of frontend like a web interface. Likely has performance and high availability requirements, as well as backup, logging, auditing, and authentication.