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> 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> 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 >>> >>> -- >>> DataStax Logo Square <https://www.datastax.com/> >>> *Mike Adamson* >>> Engineering >>> +1 650 389 6000 <tel:16503896000> | datastax.com <https://www.datastax.com/> >>> Find DataStax Online: >>> LinkedIn Logo >>> <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=> >>> Facebook Logo >>> <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=> >>> Twitter Logo <https://twitter.com/DataStax> RSS Feed >>> <https://www.datastax.com/blog/rss.xml> Github Logo >>> <https://github.com/datastax>
