Having an MVP and a limited scope sounds good to me. But I would not
remove the STORED keyword entirely from the document.
It shows that we have a long-term vision. Instead of deleting this
content, I would move it to a Outlook/Future Work section.
Regards,
Timo
On 24.10.19 10:55, Jark Wu wrote:
+1 to remove “STORED” related content. We can add them when user requires.
Others looks good to me in general.
Thanks,
Jark
在 2019年10月24日，14:58，Kurt Young <ykt...@gmail.com> 写道：
Hi Danny,
Thanks for preparing this design document. IMO It's a very useful
feature, especially combined with time attribute support to specify
watermark in DDL.
The design doc looks quite good, but I would suggest to reduce the
scope of the first version. Like we don't have to support "STORED"
in the first MVP version, and you can also delete related content in
document to make it more clean and easier to understand.
Best,
Kurt
On Tue, Sep 17, 2019 at 9:18 PM Qi Luo <luoqi...@gmail.com> wrote:
Fantastic! We're also very interested in this feature.
+Boxiu
On Tue, Sep 17, 2019 at 11:31 AM Danny Chan <yuzhao....@gmail.com> wrote:
In umbrella task FLINK-10232 we have introduced CREATE TABLE grammar in
our new module flink-sql-parser. And we proposed to use computed column
to
describe the time attribute of process time in the design doc FLINK SQL
DDL, so user may create a table with process time attribute as follows:
create table T1(
a int,
b bigint,
c varchar,
d as PROCTIME,
) with (
'k1' = 'v1',
'k2' = 'v2'
);
The column d would be a process time attribute for table T1.
Besides that, computed columns have several other use cases, such as
these [2]:
• Virtual generated columns can be used as a way to simplify and unify
queries. A complicated condition can be defined as a generated column and
referred to from multiple queries on the table to ensure that all of them
use exactly the same condition.
• Stored generated columns can be used as a materialized cache for
complicated conditions that are costly to calculate on the fly.
• Generated columns can simulate functional indexes: Use a generated
column to define a functional expression and index it. This can be useful
for working with columns of types that cannot be indexed directly, such
as
JSON columns.
• For stored generated columns, the disadvantage of this approach is that
values are stored twice; once as the value of the generated column and
once
in the index.
• If a generated column is indexed, the optimizer recognizes query
expressions that match the column definition and uses indexes from the
column as appropriate during query execution(Not supported yet).
Computed columns are introduced in SQL-SERVER-2016 [1], MYSQL-5.6 [2] and
ORACLE-11g [3].
This is the design doc:
https://docs.google.com/document/d/110TseRtTCphxETPY7uhiHpu-dph3NEesh3mYKtJ7QOY/edit?usp=sharing
Any suggestions are appreciated, thanks.
[1]
https://docs.microsoft.com/en-us/sql/relational-databases/tables/specify-computed-columns-in-a-table?view=sql-server-2016
[2]
https://dev.mysql.com/doc/refman/5.7/en/create-table-generated-columns.html
[3] https://oracle-base.com/articles/11g/virtual-columns-11gr1
Best,
Danny Chan
