Saya punya beberapa saran untuk para pembuat firebird yg sudah cukup lama saya pendam. Karena saya bingung harus post dimana, jadi saya post saja disini (situs yang selalu saya kunjungi jika ke warnet). Jika diantara rekan-rekan delphi-id ada yang bisa mengusahakan supaya para pengembang Firebird bisa 'nyasar' kesini, itu bagus sekali :D jrp / start of wish list / A Firebird wish list from another side of the globe. Dear Firebird developers, #1 It would be nice if we could use wildcards in event registering & notification. This will make Firebird’s exclusive push mechanism much much more powerful! For example, we wouldn’t need to do tricks to get the primary key of a newly inserted record. By the way, we need longer event names with this. #2 It would be nice if we had SELECT statement with a column-excluding option that enables us to specify excluded columns instead of included ones. Well I know it sounds stupid, but it is very practical. SELECT [EXCLUDING <list of columns>] So SELECT EXCLUDING emp_notes, emp_tag FROM employee will select all columns but emp_notes and emp_tag from the employee table. #3 It would be nice if we had efficient client-server conversations. IMHO Firebird is too chatty. Not to mention the uncompressed and unencrypted text flying around. It is better to implement them on Firebird, rather than relying on 3rd party software. At least please implement compression, which also serves as the cheapest mean of encryption. #4 More built-in functions are needed, please. This will keep people from nominating Firebird as a “world class DBMS with the least built-in functions”. Modularity aside, dependencies on UDFs are not good because their futures are rather unpredictable. Thank you for listening, er, reading this. / end of wish list /

Mungkin wish list ini bisa kamu kirim via email ke webmaster firebirdnews.org (done!) atau join aja ke milis firebird-support atau firebird-devel dan sampaikan disana. Sekalian iseng pengen nanggepin wish list dari jrp... / start of wish list respond by simba / #1: Agree! That'd be a nice feature. :) #2: I'm not quite agree with this. Does that syntax compliance with SQL standards (SQL-92)? It sounds like a nice feature for some lazy query writers. IMO, there's no technical benefit from this feature except save some keystrokes. :P #3: Yup, we must admit this. However, I think it's not too difficult to install 3rd party tool for this purpose. So, I doubt this'd be prioritized for the moment. #4: I'm not quite agree with this either. Firebird has been well-known as a fast database engine with small footprint yet still ensures the ACID requirement. Adding too much built-in functions into the engine will make it bloated and requires bigger resources whilst not every user need it anyway. I prefer Firebird to be accompanied with a default UDF that contains huge numbers of useful functions. This default UDF should be maintained officially by Firebird developers to make the future predictable. :D Further, users can choose and install which functions s/he want to use. I also disagree with some people who asked for non-SQL language for stored procedure (like Oracle or DB2). We're talking about a database engine here, not about a compiler. :P / end of respond / Kalo thread ini bisa "dijaga" tetep pake bhs Inggris, kita bisa bantu sampaikan topik ini tanpa harus menyertakan seluruh isinya, cukup URL thread ini aja. Kan bisa sekalian promosi situs delphi-id toh. :D Makanya, supaya gak malu kalo dikunjungi org luar, jgn bahas bajak_an secara "vulgar". :P

@simba:

#2: I'm not quite agree with this. Does that syntax compliance with SQL standards (SQL-92)? It sounds like a nice feature for some lazy query writers. IMO, there's no technical benefit from this feature except save some keystrokes.

You are right about it being off standard, having no real technical benefit, and nice for some lazy query writers :D. However, it is convenient and has practical uses. IMHO it complements good old SELECT *. It will add some flexibility in the development phase. For example, you could add new columns on a table without changing the select sql on your app (of course not for persistent-field lovers). Maybe not a good practice, but all is fair in chasing deadlines...

#4: I'm not quite agree with this either. Firebird has been well-known as a fast database engine with small footprint yet still ensures the ACID requirement. Adding too much built-in functions into the engine will make it bloated and requires bigger resources whilst not every user need it anyway. I prefer Firebird to be accompanied with a default UDF that contains huge numbers of useful functions. Further users can choose and install which functions s/he want to use.

You are correct for that bloated things. However, essential functions must sit closer to the core. Like built-in NULLIF is a good thing (since 1.5 ?). There are many good reasons to move them closer to the core. My favorite reason is that we could get some kind of warranty that they will always 'follow' the core. And I like your idea of having Firebird bundled with a huge number of well-tested functions in a default UDF.

I also disagree with some people who asked for non-SQL language for stored procedure (like Oracle or DB2). We're talking about a database engine here, not about a compiler.

While PSQL is practical and has essential elements to be called a language (e.g. branches, loops, blocks, etc) it is somewhat 'weak' compared to other programming languages these days. PSQL should be complemented with another, more robust language. With that developers could do, for example, OOP on server side. Reusability is also increased because we could import things already done on other languages with ease. Personally, I'd be happy if I could code in my native language, pascal, on the server. Well, it is about having some favorite languages inside a favorite DBMS. Thank you for commenting, and please add your wish list too. jrp

@jrp:

For example, you could add new columns on a table without changing the select sql on your app (of course not for persistent-field lovers).

I never had such a problem. I believe you know how to avoid or at least minimize it. ;)

However, essential functions must sit closer to the core. Like built-in NULLIF is a good thing (since 1.5 ?). There are many good reasons to move them closer to the core.

Agree. Essential functions must sit closer to the core, if and only if the functions are badly needed to be there. NULLIF is good example. But for other non-essential functions, I disagree.

And I like your idea of having Firebird bundled with a huge number of well-tested functions in a default UDF.

Have you looked at /udf folder? It's already there. :)

Personally, I'd be happy if I could code in my native language, pascal, on the server. Well, it is about having some favorite languages inside a favorite DBMS.

I'd be happy too. But, it's not only about favorite language or not, it's about the future maintenance. If it's written in standard PSQL, whoever the next dbadmin in charge will be able to maintain the code. It'll not be the case if it's written is some particular language which is not PSQL, say Java or Pascal, there's no guarantee that other dbadmin would have enough knowledge about the language. If I need to write server side code using my favorite language, or PSQL isn't capable enough to do the task, I'll write it as UDF or external application. This code will become developer responsibility, not dbadmin responsibility.

and please add your wish list too.

All my wish lists have been in the roadmap of the next Firebird version, e.g. full text search, cross-db query, monitoring API, etc. And first item of your wish list would be nice as well, I agree with that. :)

@Simba:

Have you looked at /udf folder? It's already there.

I had been using them already, but I'd like to see more functions in them. Particularly checksums like MD5, and string manipulation ones. On the other hand, I think bundling all-time-favorite functions with Firebird would have somewhat negative impact on people doing business selling UDFs.

I'd be happy too. But, it's not only about favorite language or not, it's about the future maintenance. If it's written in standard PSQL, whoever the next dbadmin in charge will be able to maintain the code. It'll not be the case if it's written is some particular language which is not PSQL, say Java or Pascal, there's no guarantee that other dbadmin would have enough knowledge about the language. If I need to write server side code using my favorite language, or PSQL isn't capable enough to do the task, I'll write it as UDF or external application. This code will become developer responsibility, not dbadmin responsibility.

That'is true. However the ability to code in some non-SQL languages means giving developers more ways to do things. Having some more ways to choose from is always good (but too many tend to confuse). Pure PSQL, non-SQL languages, UDFs, or combinations of them; just give developers choices and they will choose by justifying their own needs & circumstances. Worry not about bloated Firebird. I believe that Firebird core developers have good implementation strategies up their sleeves. ;) More ways to do things in Firebird ==> more people use Firebird ==> more support for Firebird development ==> better Firebird ==> even more people use Firebird ==> MS SQL Server's sales declined ==> MS gets angry ==> MS steals, er, I mean hires firebird developers ==> Firebird development stalled ==> people left Firebird ==> dead Firebird oh no :D

All my wish lists have been in the roadmap of the next Firebird version, e.g. full text search, cross-db query, monitoring API, etc. And first item of your wish list would be nice as well, I agree with that.

Yes yes yes cross-db query (at least be able to do selects accross Firebird databases on the same machine). I'm jealous to MySql users. It sure is a good tool for doing sequential development and carrying out 'divide and conquer' tactics on large projects. Silahkan rekan-rekan yang lain memasukkan wish list anda juga. Yah, siapa tahu suatu hari nanti terkabulkan. Terima kasih kepada pak Simba yang sudah memberitahu ke situs berita Firebird. jrp

On the other hand, I think bundling all-time-favorite functions with Firebird would have somewhat negative impact on people doing business selling UDFs.

Ah, again, I disagree with this POV. Providing some basic or/and common functions won't do any harms to the business, somebody will provide it for free anyway. This field isn't a place where business supposed to play on.

I believe that Firebird core developers have good implementation strategies up their sleeves.

Yeah, I believe they have. However, first things first... let them finish their main/core job which is to build a good database engine, at least until Firebird 3 is released. After the db engine is mature enough, then those not-to-important features can fill their next to-do lists. :)

More ways to do things in Firebird => more people use Firebird => more support for Firebird development => better Firebird => even more people use Firebird => MS SQL Server's sales declined => MS gets angry => MS steals, er, I mean hires firebird developers => Firebird development stalled => people left Firebird => dead Firebird

Hahahaha... it's funny, felt bitter though. :D This is what had happened on Borland and Delphi. Too good product will kill you! :lol: --- Mungkin rekan2 yg lain agak sungkan kalo pake bhs Inggris, bung JRP. Rasanya terlalu egois kalo kita maksa temen2 harus pake bhs Inggris. Jadi yg mau gabung silakan gabung aja, mau bhs Inggris atau bhs Indonesia, terserah. Cuman resikonya kalo pake bhs Indonesia, pesan2 kita disini jadi gak nyampe ke mereka.

Rekan-rekan tidak usah sungkan-sungkan. Silahkan pakai bahasa Indonesia atau Inggris (atau Delphi juga boleh kalau mau :D ) tentu boleh-boleh saja. Kalau kita lihat dalam forum-forum internasional sekalipun, tidak semua poster dapat berbahasa Inggris dengan baik, namun pengetahuan dan ide-ide mereka luar biasa. Sekedar tips sederhana untuk membantu posting dalam bahasa Inggris: gunakan fasilitas spelling & grammar checker yang sudah ada di word processor anda. Bisa banyak membantu beneran. Kita tidak berharap terlalu banyak apakah akan dibaca dan ditanggapi oleh para developer Firebird, tapi ini lebih baik daripada tanpa usaha sama sekali. Saya tahu banyak pemakai Firebird termasuk yang produknya sudah dipasarkan secara nasional yang 'bersembunyi' di delphi-id. Ayolah, selama pakai Firebird anda pasti punya harapan / uneg2. Silahkan ditulis ya... Terima kasih. jrp