←back to thread

Show HN: Base, an SQLite database editor for macOS

(menial.co.uk)
676 points __bb | 1 comments | 25 Aug 25 14:17 UTC | HN request time: 0.302s | source

I recently released v3 of Base, my SQLite editor for macOS.

The goal of this app is to provide a comfortable native GUI for SQLite, without it turning into a massive IDE-style app.

The coolest features are

- That it can handle full altering of tables, which is quite finicky to do manually with SQLite.

- It has a more detailed display of column constraints than most editors. Each constraint is shown as an icon if active, with full details available on clicking the icon.

This update also adds support for attaching databases, which is a bit fiddly with macOS sandboxing.

I'd love to hear any feedback or answer any questions.

Show context
gwbas1c ◴[25 Aug 25 15:23 UTC] No.45014862[source]▶
> Create and modify tables with ease using Base's visual table editor. No need to write complex CREATE or ALTER statements.

I'm trying to understand who your target audience is? Normally, I think of SQLite as something that only a programmer would use. (And thus these kind of statements happen within an application.)

What kind of use cases are you handling where someone is manually creating / changing a schema?

> Import data from CSV and SQL dump files. Export your results to SQL, delimited text, JSON, and Excel formats.

IE, who's using SQLite in this way, and what are they using it for?

replies(11): >>45014969 #>>45015101 #>>45015221 #>>45015820 #>>45016671 #>>45017071 #>>45017737 #>>45017748 #>>45018213 #>>45023872 #>>45024084 #
1. millerm ◴[25 Aug 25 19:12 UTC] No.45017737[source]▶
> And thus these kind of statements happen within an application.

Who made that rule? Most database tools I have used do this. I can go into SQLite's command interface and do it. It's not limited to the application.

Not all of us want to write code for everything. Sometimes when I'm developing an app or an idea, the last thing I want to do is keep messing with cruft I don't have to. It's a waste of time to write yet another alter/create/etc script. I just click and change it. That's it, and I move on. I don't care until my design is done to export/create the creation/alter scripts, if I even need them, because I can ship a fully set up DB file with the app, I don't actually have to have scripts for that stuff. Sure, later I may need to on an update, but when rapidly prototyping I'd rather just have the quickest way to deal with it. Else, the argument becomes "Why not just use the SQLite terminal interface instead of a graphical tool?" or "Why would you create or rename a directory using Finder rather than a shell script to do it?"

> IE, who's using SQLite in this way, and what are they using it for?

Anyone that wants to do such things? I just recently wrote an app that runs in a browser using only javascript, but in the end I wanted the data and it exports it to JSON so I can load it into another app. I haven't gotten around to integrating these (and I probably won't) as the app is a pure browser application, but the other is a tool for creating TTML2 documents, and I need that data. So, I can easily import that. It's not a commercial thing, it's my own. So, I don't want to merge the two. I don't mind the step. This sort of thing is good. What is wrong with the ability to do so? PostgreSQL can do it. You don't believe it could be useful to export your data so that someone that isn't using SQLite can view it? Dumping a table for viewing in Excel is so common that I don't really understand why you're asking.

There are literally billions of devices using SQLite. And within those devices, countless applications are using the thing. Do you believe it has a limited set of use cases? Heck no.

Your questions seem like bait and I bit.