I'm sure you'll get others, but ElevateDB fits your needs.
It's the follow-on to DBISAM, which does NOT have Unicode support. But ElevateDB does.
Chris Thornton
2010-09-20 17:59:22
views:
380answers:
7
+1
A:
and if you apply over it the IBObjects component suite things became very easy.
Radu Barbu
2010-09-21 08:10:28
It looks like best solution will be Firebird or MS SQL.. Thanks to all people who helped. I mean all of you ;)
Alper
2010-09-23 20:59:02
+1
A:
May I suggest to take a look at NexusDB. It also fits all your needs. Bill Todd has just reviewed the product.
Erwin
2010-09-20 19:21:29
Any benefits compared to Firebird? After all, Firebird is free.
Muhammad Alkarouri
2010-09-20 19:25:55
People usually suggest the database they use and like instead of understanding the requirements and then selecting a database. I saw too many company with a whole bunch of different database engines because each software required its own instead of taking advantage of existing resources
ldsandon
2010-09-20 22:10:46
FireBird is a good database of course. With NexusDB the data-access components are included. It also comes with a management tool for database maintenance. And I think FireBird versions don't scale very well on SMP machines. BTW, the embedded version of NexusDB is also completely free. There are of course many good databases around for Delphi. Since Bill Todd is recognized as a Delphi and database expert for years by the Delphi community, I thought people would like to know his view on NexusDB.
Erwin
2010-09-21 20:54:19
Better SMP support should come in 3.0. Meanwhile Classic works better than SuperServer as long as there are not too many users. Interbase should have better SMP support, but it is not free. Also querying "huge amount of data" could benefit from 64 bit support (larger memory caches).
ldsandon
2010-09-21 21:44:42
@Idsandon: LOB? Please elaborate, my brain is suffering from acronym depletion... :)
Marjan Venema
2010-09-21 06:14:54
Large OBject. Usually comes in Character LOB (CLOB, sometimes called Text fields) and Binary LOB (BLOB, sometimes called in other ways) flavours. Useful to store large, unstructured data.
ldsandon
2010-09-21 07:29:37
Of course PostgreSQL has LOB support: http://www.postgresql.org/docs/9.0/interactive/largeobjects.html . You can use it from LibPQ library (I do it using Delphi, Kylix and FPC). Also remember that PostgreSQL VARCHAR can store much more data then VARCHAR from Informix or Oracle.
Michał Niklas
2010-09-22 07:47:33
I never told Postgres has no LOB support. It has no *decent* LOB support. It has strange LOBs where LOBs are written to a separate common table. You can't declare fields of type (B/C)LOB, you have to use OID fields (although text fields are available). They also are smaller then other LOB implementations, although for most people hitting those limits is uncommon.
ldsandon
2010-09-24 22:01:49
+2
A:
Most of your requirements are handled by most modern database engines (althout concurrency management is not exactly the same among all databases). But to choose the database(s) that would suit you best you should give more precise informations:
- "Multiple users". How many concurrent connections? 10? 100? 1000? 10000? 100000? More?
- "More than one user should be able add new records at one time". How many inserts per hour? Is this an OLTP database, or a DW one?
- "Capable of storing huge amount of data". How many tables? How many rows? How many fields? What's the average row size? Do you need LOB support? How many indexes?
- "Users can be able to edit their own records". How often? How many? How long? Some databases have better locking mechanism than others.
- "Unicode enabled". Which flavour? UTF-8? UTF-16?
- "All records will be string". Which is the maximum string length you need? Hope they are "natural" string fields - storing non-natural string data in string fields usually lower performance.
ldsandon
2010-09-20 22:08:55
A:
"Users can be able to edit their own records" What does it mean for you? A database in which records are not editable, that is a Read/Only database, is not very common.
You'll have to think about the general architecture of your software. You just don't select a database like a new car. I'd suggest that you won't be focused on the database choice, but take a look at the whole picture.
Here are some advices:
Separate your database storage, the User Interface, and your software logic. This is called 3-Tier, and is definitively a good idea if you're starting a new project in 2010. It will save you a lot of time in the future. We use such an architecture in our http://blog.synopse.info/category/Open-Source-Projects/SQLite3-Framework
Use a database connection which is not fixed to one database engine. Delphi comes with DBX, and there are free or not so expensive alternatives around. See http://edn.embarcadero.com/article/39500 for dbx and http://www.torry.net/pages.php?id=552 for alternatives
Think about the future: try to guess what will be the features of your application after some time, and try to be ready to implement them in your today's architecture choices.
In all cases, you're right asking for advice and feedback. The time you're spending now before coding will spare your time during future maintenance.
For example, if one of your request is that "All records will be string", with some BLOB, your database size won't never be bigger than a few GB. SQLite3 could be enough for you, and there is no size limitation in the TEXT fields in this database.
A.Bouchez
2010-09-21 07:04:42
SQLite locking mechanism is not the best for high concurrency - writers lock the whole database. Even before deciding how to code your application, you have to understand how your application needs to use your database - and then select a database that works best in that scenario (as long as the database is not "given" and not changeable) within your budget.
ldsandon
2010-09-21 08:02:16
SQLite locking has been upgraded a lot, with the new WAL journaling system, included since version 3.7. Concurrency is now very good for reading, but writers still lock the whole DB, but it's very fast in practice, since most DB usage scenarii do much more reading than writing. I'm not sure that Alper knows his exact needs about DB and storage. In all cases, it could be a good idea to look after the ORM approach for a new software. There are multiple threads about Delphi ORM in stackoverflow.
A.Bouchez
2010-09-21 09:16:23
Updating and deleting is writing too. Everything depends on the database usage profile. Whatever approach one uses to access the DB it has to face concurrency issues. Unless the middle-tier serializes everything <g>
ldsandon
2010-09-21 11:17:17
@ldsandon : you're perfectly right. In fact, the middle-tier can makes the concurrency much better than direct access to a database: for example, we implemented a simple caching mechanism in our framework, and it increased concurrent readings performance a lot.
A.Bouchez
2010-09-23 09:35:37
"Users can be able to edit their own records" What does it mean for you? A database in which records are not editable, that is a Read/Only database, is not very common.I mean only the record owner will be able to edit their record...I just wanted to desribe that i need editable database.
Alper
2010-09-23 20:51:46
A:
Nobody's mentioned SQL Server Express so I guess I'll do it...
Microsoft SQL Server Express is jolly good and is also free.
Yes, it does have limits but they're pretty big and it's not possible to know if they're sufficient without further info from the OP.
- Multiple users enabled - yep
- More than one user should be able add new records at one time - yep
- Capable of storing huge amount of data - depends on definition of huge. But "probably"
- Users can be able to edit their own records - umm, yes
- Unicode enabled - yep
- As possible as low cost solution - it's free. But the data access components will depend on your choice of access method
shunty
2010-09-21 10:28:47