Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I recently switched a project from MySQL InnoDB to PostgreSQL, and I feel bigger lags when inserting and updating data with ajax. This may be subjective. I know the Django devs recommend postgres and I know psycopg2 is supposed to be faster than MysqlDB. Personaly I like the way postgres enforces database integrity, but am mostly worried about performance for this project. Want to hear other people's opinion on this.
Why don't you measure? That's the only way to be sure about the performance. Hand waving about how slow or not is something without hard data is like trying to catch water with your hands.
Measure transactions per second or even better, requests per second with a web server stress tool like The Grinder (which can be scripted in Jython) with both MySQL backend and PostgreSQL and afterwards see if that makes a difference. If it does, ask around here, or, more specifically, ask on the pgsql-general or pgsql-performance mailing lists. There are many expert people there which know loads about it, even the main devs. There are tons of knobs on PostgreSQL configuration related to performance.
It may be incorrect usage of indexes. Simply making sure you have the right indexes, and making sure the tables are analyzed and vacuumed periodically should give rather decent results.
Even if Postgres turns out to be a minuscule slower, in some cases, my personal opinion is that the features it provides greatly outweigh the minor performance losses.
Postgres really is a beautiful database, and any time I'm using anything else, I wish I was using Postgres.
I used SQLite for the first time in the development phase of the last project. It is easy to set up, convenient to carry around from one dev system to another, etc. I have to add that when I finally moved the project to production over on MySQL, a number of subtle issues manifested themselves with MySQL that were not present at all with SQLite. Nothing big, but from now on if I have to deploy a project on MySQL, I would prefer to use MySQL in the development phase too.
SQLite. No backend server. Excellent for dev
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've looked at both Liquibase and Flyway individually and on an individual comparison alone, Liquibase seems like the better tool for our needs. Some sources mention using both Liquibase and Flyway together. Liquibase seems to have everything Flyway has and more flexibility when it comes to rollbacks. The main advantage of just Flyway seems to be not having to use XML, but Liquibase allows you to specify an SQL file in their XML.
Basically, I'm still not clear on what the benefits of using Flyway & Liquibase together would be over just Liquibase, if there are any. Maybe there's a way to do it I'm not seeing as even if Liquibase was referring to valid Flyway SQL files, both tools would have to be run independently and still have the same pitfalls even though you could technically use either tool.
A small correction, before I answer question. The assumption
Liquibase seems to have everything Flyway has
isn't correct. Flyway shines when it comes to parsing SQL. You can use unmodified SQL files generated by your native tools containing all kinds of complexity like PL/SQL packages and procedures, MySQL delimiter changes, T-SQL, PostgreSQL procedures, ... With Liquibase you would have to split these in individual statements, add extra comments to the SQL files, ...
The beauty of being able to use your SQL files as-is is that you avoid lock-in. You can take your existing SQL files, start using Flyway with minimal investment and moved away later if it doesn't suit your needs anymore. Not so with Liquibase.
Also the issue of down migrations (think of them as compensating transactions, not rollbacks) is really something that sounds great in theory, but that is almost never needed in practice. See this old documentation page¹.
However when it comes down to using one or both, I certainly agree with SteveDonie (Liquibase team member) that using just one instead of the both together is almost always the better choice.
Disclaimer: I am Flyway's creator
¹ Though Flyway does support undo migrations nowadays, by reading the old documentation you'll understand the point Axel Fontaine is trying to make.
I would never recommend using both tools at the same time. In my experience, even only one of them causes conflicts/collisions from time to time in a big distributed environments(over 5 teams with access to the same DB).
I will also give you a couple of pros and cons when it comes to running these tools in projects with big, distributed teams:
FlyWay:
Cons:
Very strict when it comes to migration files changes. If someone checked in their migration file, it is not recommended to change it. It's like using force push in git in shared projects. Changing a migration(either its content or the file's name) will cause a migration failure on every machine that had the previous version of the file. The whole migration pack will need to be run from scratch. In some cases it can take a lot of time.
Pros:
Well, what was described in Cons will, at the same time, build up a level of discipline. It might be a reasonable restriction when talking about introducing simultaneous changes by several teams to a production-running application.
Liquibase:
Cons:
With a couple of tweaks should allow you to change the existing(applied) migrations. While it can be considered as a benefit, with a lot of people working on the same codebase, extra caution should be exercised. Flexibility comes at a price. It's easier to introduce some "regression" or inconsistency when such "git force push" style of changes is allowed for distributed projects.
Pros: More configurable and more flexible. Might include solutions for NoSql in the future. A couple of useful plugins(hibernate integration, for example).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are aiming to leverage software reuse in embedded ARM/Linux platforms. Some of our hardware platforms are designed for customers' specific needs. Of course the application would be customized in various ways too.
While it is not an Android product, for one it is way too big compared to ours, it does make a good analogy in that other than the constant of being Linux based, there are different look and feel to the UI, there are different phones, there are different CPUs, there are different firmwares for different radios, etc. So there are many configurations to manage. And the configurations are a sparse matrix, in that not all combinations exist.
Continuous Integration is also not completely out of the picture in the future.
So for the near future the end point seems to be:
A core set of libraries that we want to keep developing and apply everywhere. Class inheritance supplies the customizations. So there is a build configuration for the application types.
A handful of customized ARM/Linux hardware platforms. Seems a BSP/board class HAL for our libraries is the way to go. That means a build configuration to pick the right hardware/board.
A handful of co-processor firmwares matching to the hardware/board, but the API to our libraries is the same. So there is a build configuration depending on the firmwares.
A handful of implementation for different look and feel/applications. That's another build configuration.
Needless to say there are many include paths, #define's, and file exclusions to make all these work.
So as you can see, if we wanted a collection of Eclipse/CDT projects in a workspace that allows us to build all these variants in the same environment all at once, there are a lot of configurations to create and manage in Eclipse/CDT. If the GUI is the only way to manage, there is a whole deal of mouse clicking to do. And after that there is no simple way to verify that all configurations are setup correctly without a whole lot more mouse clicking. There isn't a dashboard view. Is there a text editor based approach to manage all these?
I did try to do my homework. I understand that there is the 'Import Settings...' and 'Export Settings...' buttons in the 'Paths and Symbols' tab. But it does one configuration at a time, for one project at a time. It doesn't seem very systematic and is easy to miss something.
I have also look directly at .cprojects but I worry that if I made a mistake Eclipse will just silently do the unexpected things and will take big effort to fix.
Do fellow experts have a better suggestion?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I found around 8 Strenghts and flaws of using APEX over another program(http://en.wikipedia.org/wiki/Oracle_Application_Express), but i am not sure i quite understand WHEN to use it.
From what i understand, if you want a fast and easy-to-use development tool related to Oracle, Apex is your first choice. While if you need a complex solution, APEX won't fit.
I would like to know you guys opinion on this. In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented. We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates.
Apex is free, and an oracle XE database is free too. Apex is rapid development.
But what you're asking depends on so much more.
From what i understand, if you want a fast and easy-to-use development
tool related to Oracle, Apex is your first choice.
Is an oracle database already being used?
Easy to use dev tool: yes, sure. But as with anything, it depends on whether you have some experience with it, what the specs and expectations are, ...
While if you need a complex solution, APEX won't fit.
Well,... Would a complex solution be so much less complex in another environment? Just how complex are we thinking? In my opinion, you can go pretty far in apex and adapt it to your needs. it might involve creating templates and plugins to set up a framework, but it is doable. An example would be apex projects whom have been completely integrated with ExtJS. Apex is not the answer to everything too, but it's good. If you'd stay within the Oracle stack for more involved/complex, i'd say the next thing is ADF. Personally, i'm not convinced by that one though. It also has its pros and cons (such as: requiring java knowledge. pro for some, con for others...)
In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented.
How large is this club? How intense will the website be used?
Is there a DB already? Is it Oracle?
Who has DBA knowledge (even basic)?
Who will develop?
If your specs are up to spec, then much fiddling shouldn't be necessary after the launch.
We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates
Who will host the server? Who will run it? Who will administrate it? Do you plan to go cloud-based?
I'd almost ventured to suggest PHP may be a good alternative if this is a small project. Those developers may be easier to find and less expensive than an apex/oracle developer. But then again, if you're planning to outsource it may be less of an issue. If your oracle instance would be in the cloud somewhere, you'd even be pretty safe i'd believe...
Really, what options are you trying to compare? You're asking about apex, do you have any experience with it?
Honestly, your question is not so much a question as it is an opener to a discussion. Each technology and database will have its pro's and cons, fans and dislikers.
Personally, i really like apex. It has a lot going for it, especially when you're already invested in the Oracle stack. And it is still growing, getting good support, and great releases with lots of new features.
I can't really say how it must be set up a (reliable) service from the ground up: server and database, doesn't matter how small, you'll need some understanding and knowledge for that. If you just wing it and cross your fingers, you'll burn them somewhere down the line. Same with development. But as far as i'm concerned that goes for any other tech. Unless you outsource those aspects of course.
Etc etc. There is much and more to be discussed this way.
I put a downvote there for these reasons: there is much to be discussed, it isn't really much of a question which has a conclusive answer. And it maybe only could fetch a conclusive answer if you put more specifications up there and get people of the concurrent platforms to respond.
Edit
I'd like to react on Daniel's post.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
I'm a developer too, and i don't do server and database administration (corporate environment). Not that i haven't dabbled a bit here and there in my spare time, but i digress.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
So speaking as a PHP developer, would you even recommend PHP to achieve this? Would it be less or just as complex?
I'd also argue about complexity. I've worked on some large forms, which for me by now means there are more than your average amount of items, some dynamic actions, validations, maybe some custom process(es). I've not encountered extremely complex situations and honestly i'd question who created those expectations. Thinking outside the box may be a virtue at times, but that doesn't mean the box is always bad. Complex mechanisms or pages can maybe be broken down into more easily accomplishable parts. An example would be using modal pages to break it up.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms.
I agree about limited programming experience: you'll only create the most basic forms and reports, and having almost no experience i'd think you'd shy away from even option pages in fear of breaking something. Same thing goes for even basic db and server administration: i wouldn't like to rely on such a person when there is no experienced backup (but a very small project as is apperently being described might be acceptable).
I too am only invested in the programming side.
It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
I'd say that the templates make things very flexible and are certainly not hard to use
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Wow. I strongly disagree with this. I've maybe encountered one such thing over the course of a year and tons of forms. Not that i haven't heard of some problems on the OTN forums, but usually they had to do with upgrades.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
It is too bad that there are not that many large, public sites which use apex out there. As far as i'm aware, there are and have been large project involving apex, but those usually are in a corporate environment and thus are never shown off (can't be). I personally believe apex can be pushed a lot further than the basic forms+reports you mention (and i mean basic, because things will usually come down to forms+reports in this context).
Debugging does not have to be a pain though. If you provide enough debug messages and comments in your own code, that will help a great deal. Debugging the page, javascript console, and if needs be an autonomous error logging procedure to be used in your plsql packages,... I'd say there is plenty to help out (and if you're driven to this, you are working on some more complex material, and i assume that you have the knowledge to actually deal with the complexity you've set up).
And interesting point you raise lastly is maintenance though. I'd say a point on which apex should improve a lot is versioning, out of the box. Exports need to be improved so they can be broken up a lot easier.
Wow, look at that wall of text... I could've guessed this would turn out into a discussion.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
To start we created a few applications, just to get a feeling. Afterwards we started with the easy parts of the application. APEX is really great if you only have to build some reports and forms to edit the entries of the database. It's very fast to create these things with the integrated wizards.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms. It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
I am posting here as a guest--hopefully, I will create an account. I used O-HTML-DB from its early releases. We built pretty fine apps. I last used it in 2004, having moved to non-development roles.
Since 2007 though, I decided to revisit the tool and found out about APEX. I have since had my own test apps. I disagree with most of what the intern says.
If you have a limited objective (your business need and associated requirements), then your use of APEX will be limited. This is a very robust application, with sophisticated security features (I have been in InfoSec/Cyber since 2009.
Yes, you are correct than claims about APEX not requiring a solid development background are not accurate. You need to have a sound grasp of SQL/PL/SQL, JavaScript. But you c an also take great advantage of OTN, where developers generously share their know-how. When I started with O-HTML-DB, I had never built a DA in a business environment before. I had theoretical SQL skills. I was a Web Developer with a grasp of JavaScrip, training in Java from Learning Tree International (in addition to academics). But I and my colleague (we were two developers) learned a great deal from OTN. We built three Web apps, one of which supported over 6,000 users--just O-HTML-DB!
APEX has taken O-HTML-DB to new dimensions. You do not need to hard-code validations like we did with O-HTML-DB. Of course, you can modify, which requires a sound grasp of SQL/PL/SQL.
Maybe templating is somewhat confusing to many developers, understandably. But as you continue to "play" with APEX, I am sure you'll like it. It can do nearly anything. Only your limited vision will restrict it.
Erick
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
We need an in-memory data structure / DB server with following characteristics:
stand-alone server: will run on the same machine as the clients, so any kind of IPC is ok
sequential access: get next/previous key
two keys (string) per record: kind of a bi-directional map, actually
in-memory only: should have option for no persistence at all
RAM disk/tmpfs solution is not desirable
SQL/ODBC is an option, although not required
commercial product ok, if the OEM license price is reasonable
So far we have considered the following options, but no satisfactory solution yet:
mysql: answers all requirements, but now answer yet as to how much an OEM license will cost
memcached, cassandra: no sequential access, according to online docs
Redis: seems as a nice tool, but again, I don't see get get nex/prev in the spec
Postgres: couldn't make it work well on Linux/ODBC
Seems that all nosql in-memory DBs provide only direct access by key, hash-table style.
Have not checked Apache Derby yet.
We run on Linux, the client is in C++.
Will be glad to have your suggestions. Thanks!
EDIT: It seems that we will be pursuing the mysql option, we've got a reasonable price offer, and it will also be useful as our main (persistent) DB. Thanks for all answers, it is as usual difficult to select just one.
I'd have a look at SQLite, with the database file name set to ":memory:" this will create an in memory database that will no longer exist when your application closes.
It is public domain so that there is no issue with licensing
FastDB should work just fine. It supports in-memory configuration and shared access.
Redis doesn't sort keys, but it does have lists/sets which allow you to retrieve items in order. It's hard to know for sure if that would work without knowing why you want sequential access, but with NoSQL you often need to think a little differently about the data structures you use.
I'd suggest Kyoto Cabinet, it has an in memory function and sequential access.
edit:
what's wrong with stl map?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Our team is moving into much larger projects in size, many of which use several open source projects within them.
Any advice or best practices to keep libraries and dependancies relatively modular and easily upgradable when new releases for them are out?
To put it another way, lets say you make a program that is a fork of an open source project. As both projects grow, what is the easiest way to maintain and share updates to the core?
Advice regarding what I'm asking only please...I don't need "well you should do this instead" or "why are you"..thanks.
With clones of open source projects one of your biggest headaches will be keeping in sync/patched according to the upstream sources. You might not care about new features, but you will sure need critical bug fixes applied.
My suggestion would be to carefully wrap such inner projects into shared libraries, so you can more or less painlessly upgrade just those parts if the ABI is not broken by the changes.
One more thing - if you find and fix bugs in an open source project - don't keep the fixes to yourself. Push the patches upstream. That will make the project better and will save you days of merging with a new version.
In order of preference
Make as few changes as possible to the third party libraries. Try and get around their limitations within your code. Document your changes and then submit a patch.
If you can't get around their limitations, submit your change as a patch (this may be idealistic with the glacial pace of some projects).
If you can't do either of those things, document what you've changed in a centralized location so that the poor person doing the integration for new versions can figure out what the heck you were doing, and if the changes made are still needed.
1 and 2 are greatly preferred (however, fast and very slow respectively), while the third option will only lead to headaches and bugs as your code base deviates from the dependencies' code base. In my code, I don't even have the 3rd party code loaded up in the IDE unless I have to peruse a header file. This removes temptation to change things that aren't mine.
As far as modularity, and this is assuming you are using relatively stable 3rd party libraries, only program to the public facing interface. Just because you have the source doesn't mean you have to use it all over your code. This should allow updates to be essentially drag and drop. Now, this is completely idealistic but its what I strive for with code I work on.