The features below are not yet implemented in MySQL 4.1, but are planned for implementation before MySQL 4.1 moves into its beta phase. For a list what is already done in MySQL 4.1, see section 1.6.1 Features Available in MySQL 4.1.
Development of other things has already shifted to the 5.0 tree.
| Posted by Federico Razzoli on Wednesday September 18 2002, @3:08pm | [Delete] [Edit] |
You are implementing and planning to implement very useful
functions/features. But BEFORE THAT I think you should
implement some powerful Sql instructions: all Join types,
INTERSECT, MINUS and EXCEPT. You also should focus on
speed, because complex Sql queries could be slow. Anyway,
subselects and derived tables are great.
| Posted by Bernhard Lukassen on Tuesday May 6 2003, @1:30am | [Delete] [Edit] |
If you are implementing the GROUP BY ROLLUP please do not forget the GROUP BY CUBE! Also provide a function that the aggregation levels in the result set can be marked and found. E.g. the function GROUPING_ID() like in Oracle. Also some Analysis function like RANK(), DENSE_RANK(), LAG() LEAD(), ... may be usefull.
| Posted by Anonymous on Sunday May 18 2003, @7:12pm | [Delete] [Edit] |
When using replication, sometimes you want to know if two databases are the same. It would be nice to be able to compare two databases, and produce a diff.
To save network bandwidth, it would be nice to be able to get checksums of tables and/or rows.
select id, sha1(*) from employees;
Or from a set of rows:
select id, sha1(*) from employees where id >= 0 and id < 20;
Or maybe from an entire table:
sha1 (select * from employees);
I'm no sql expert so I'm not sure if that's the correct way of doing this.
A program (mysqldiff?) could then connect to two databases, compare the tables row-for-row or table-for-table (or N rows at a time).
The output could simply be SQL; a set of insert/update/delete statements which would make the first database the same as the second.
| Posted by Ben Margolin on Monday June 2 2003, @4:54am | [Delete] [Edit] |
Stuff I think is more important (more important than OLAP--if you need OLAP, buy something heavy duty--you can probably justify the cost.)...
- SPs. *Versionable*. Yes, I know it's coming in 5.0... I'd love it to have (a) pluggable syntax (php would be first choice after the ansi syntax) and (b) easily-controlled with cvs or other rev control. So needs to support "SHOW PROCS LIKE *", "DESCRIBE PROC", etc. in addition to the usual stuff.
- XML resultsets. Nothing too fancy, don't need schemas yet, etc. But basic XML results. HOWEVER, please make it efficient--the actual text tags should NOT be sent back--compress them and send the compression tree back, and have the client do the expansion. I believe sql server 2000 sp2(?) is now doing this, and it's a cool feature, and not just for XSL'ing the results for the web (although great for that, of course.) Ideally you want to be able to apply a XML schema to the data to transform it as it query is sent back, but I can wait on that one.
| Posted by q q on Tuesday July 22 2003, @10:54am | [Delete] [Edit] |
community need REPLICATION, like merge, or transactional mostly