FYI we support SCHEMA as an alias to KEYSPACE today (have since always). Can use CREATE SCHEMA in place of CREATE KEYSPACE, etc.
> On 4 Apr 2023, at 19:23, Henrik Ingo <henrik.i...@datastax.com> wrote: > > I find the Postgres terminology overly complex. Where most SQL databases will > have several *databases*, each containing several *tables*, in Postgres we > have namespaces, databases, schemas and tables... > > Oracle seems to also use the words database, schema and tables. I don't know > if it has namespaces. > > Ah, ok, so SQL Server actually is like Oracle too! > > > So in MySQL, referring unambiguously (aka full path) to a table would be: > > SELECT * FROM mydb.mytable; > > Whereas in Postgresql and Oracle and SQL Server you'd have to: > > SELECT * FROM mydb.myschema.mytable; /* And I don't even know what to > do with the namespace! */ > > > https://www.postgresql.org/docs/current/catalog-pg-namespace.html > https://www.postgresql.org/docs/current/ddl-schemas.html > https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821 > https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081 > https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16 > https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16&tabs=sqlpool > > The Microsoft docs perhaps best explain the role of each: The Database > contains the configuration of physical things like where on disk is the > database stored. The Schema on the other hand contains "logical" objects like > tables, views andprocedures. > > MongoDB has databases and collections. As an easter egg / inside joke, it > also supports the command `SHOW TABLES` as a synonym for collections. > > A TABLESPACE btw is something else completely: > https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053 > > > > Personally I would be in favor of introducing `DATABASE` as a synonym for > KEYSPACE. The latter could remain the "official" usage. > > henrik > > > On Tue, Apr 4, 2023 at 8:32 PM Jacek Lewandowski <lewandowski.ja...@gmail.com > <mailto:lewandowski.ja...@gmail.com>> wrote: >> While for someone who already knows Cassandra keyspace is something natural, >> for newcomers it is yet another concept to understand. >> >> If namespace is used in PostgreSQL, it sounds even better to me. >> >> Thanks, >> - - -- --- ----- -------- ------------- >> Jacek Lewandowski >> >> >> wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh <rahul.xavier.si...@gmail.com >> <mailto:rahul.xavier.si...@gmail.com>> napisał(a): >>> My 2 cents: >>> >>> Keeping it keyspace works for me, namespace could be cool also since we >>> decide where that namespace exists in relation to Datacenters, etc. In our >>> case, a Keyspace is more similar to a namespace than it is to a database >>> since we expect all the UDTs,/UDFs, indexes to refer to only the tables in >>> that keyspace/namespace. >>> >>> Alternatively interesting to observe and throw some fuel into the >>> discussion , looking at the Postgres (only because there are many >>> distributed databases that are now PG compliant) : >>> From the interwebs: In PostgreSQL, a schema is a namespace that contains >>> named database objects such as tables, views, indexes, data types, >>> functions, stored procedures and operators. A database can contain one or >>> multiple schemas and each schema belongs to only one database. >>> >>> I used to gripe about this but as a platform gets more complex it is useful >>> to organize PG DBs into schemas. In C* world, I found myself doing similar >>> things by having a prefix : e.g. appprefix_system1 appprefix_system2 ... >>> >>> >>> Rahul Singh >>> Chief Executive Officer | Business Platform Architect >>> m: 202.905.2818 e: rahul.si...@anant.us <mailto:rahul.si...@anant.us> li: >>> http://linkedin.com/in/xingh >>> <https://urldefense.com/v3/__http://linkedin.com/in/xingh__;!!PbtH5S7Ebw!afY0-NqkBo2VBXvYyGP5lw6NYraugbMkyajfgaclPqGA_RwsPArxv94zXqkLosh3gEPQic8gVFLDnqRH_j86oWy7IviuNA$> >>> ca: http://calendly.com/xingh >>> <https://urldefense.com/v3/__http://calendly.com/xingh__;!!PbtH5S7Ebw!afY0-NqkBo2VBXvYyGP5lw6NYraugbMkyajfgaclPqGA_RwsPArxv94zXqkLosh3gEPQic8gVFLDnqRH_j86oWwrKOuxdg$> >>> We create, support, and manage real-time global data & analytics platforms >>> for the modern enterprise. >>> >>> Anant | https://anant.us >>> <https://urldefense.com/v3/__https://anant.us/__;!!PbtH5S7Ebw!afY0-NqkBo2VBXvYyGP5lw6NYraugbMkyajfgaclPqGA_RwsPArxv94zXqkLosh3gEPQic8gVFLDnqRH_j86oWy4zsWIsA$> >>> 3 Washington Circle, Suite 301 >>> Washington, D.C. 20037 >>> >>> http://Cassandra.Link >>> <https://urldefense.com/v3/__http://cassandra.link/__;!!PbtH5S7Ebw!afY0-NqkBo2VBXvYyGP5lw6NYraugbMkyajfgaclPqGA_RwsPArxv94zXqkLosh3gEPQic8gVFLDnqRH_j86oWxYYQnYHg$> >>> : The best resources for Apache Cassandra >>> >>> >>> On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa <jji...@gmail.com >>> <mailto:jji...@gmail.com>> wrote: >>>> KEYSPACE at least makes sense in the context that it is the unit that >>>> defines how those partitions keys are going to be treated/replicated >>>> >>>> DATABASE may be ambiguous, but it's ambiguity shared across the industry. >>>> >>>> Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because >>>> it'll be unique to us in the world, and therefore unintuitive for new >>>> users. >>>> >>>> >>>> >>>> On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie <jmcken...@apache.org >>>> <mailto:jmcken...@apache.org>> wrote: >>>>> I think there's competing dynamics here. >>>>> >>>>> 1) KEYSPACE isn't that great of a name; it's not a space in which keys >>>>> are necessarily unique, and you can't address things just by key w/out >>>>> their respective tables >>>>> 2) DATABASE isn't that great of a name either due to the aforementioned >>>>> ambiguity. >>>>> >>>>> Something like "TABLESPACE" or 'TABLEGROUP" would theoretically better >>>>> satisfy point 1 and 2 above but subjectively I kind of recoil at both >>>>> equally. So there's that. >>>>> >>>>> On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote: >>>>>> I agree with Bowen - I find Keyspace easier to communicate with. There >>>>>> are plenty of situations where the use of "database" is ambiguous (like >>>>>> "Could you help me connect to database x?"), but Keyspace refers to a >>>>>> single thing. I think more software is moving towards calling these >>>>>> things "namespaces" (like Kubernetes), and while "Keyspaces" is not a >>>>>> term used in this way elsewhere, I still find it leads to clearer >>>>>> communication. >>>>>> >>>>>> -- >>>>>> Abe >>>>>> >>>>>> >>>>>>> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña <adelap...@apache.org >>>>>>> <mailto:adelap...@apache.org>> wrote: >>>>>>> >>>>>>> I think supporting DATABASE is a great idea. >>>>>>> >>>>>>> It's better aligned with SQL databases, and can save new users one of >>>>>>> the first troubles they find. >>>>>>> >>>>>>> Probably anyone starting to use Cassandra for the first time is going >>>>>>> to face the what is a keyspace? question in the first minutes. Saving >>>>>>> that to users with a more common name would be a victory for usability >>>>>>> IMO. >>>>>>> >>>>>>> On Tue, 4 Apr 2023 at 16:48, Mike Adamson <madam...@datastax.com >>>>>>> <mailto:madam...@datastax.com>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to propose that we add DATABASE to the CQL grammar as an >>>>>>> alternative to KEYSPACE. >>>>>>> >>>>>>> Background: While TABLE was introduced as an alternative for >>>>>>> COLUMNFAMILY in the grammar we have kept KEYSPACE for the container >>>>>>> name for a group of tables. Nearly all traditional SQL databases use >>>>>>> DATABASE as the container name for a group of tables so it would make >>>>>>> sense for Cassandra to adopt this naming as well. >>>>>>> >>>>>>> KEYSPACE would be kept in the grammar but we would update some logging >>>>>>> and documentation to encourage use of the new name. >>>>>>> >>>>>>> Mike Adamson >>>>>>> >>>>>>> -- >>>>>>> <https://www.datastax.com/> >>>>>>> Mike Adamson >>>>>>> Engineering >>>>>>> +1 650 389 6000 <tel:16503896000> | datastax.com >>>>>>> <https://www.datastax.com/> >>>>>>> Find DataStax Online: >>>>>>> >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=> >>>>>>> >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=> >>>>>>> <https://twitter.com/DataStax> >>>>>>> <https://www.datastax.com/blog/rss.xml> <https://github.com/datastax> >>>>> > > > -- > > Henrik Ingo > c. +358 40 569 7354 > w. www.datastax.com <http://www.datastax.com/> > <https://www.facebook.com/datastax> <https://twitter.com/datastax> > <https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
