• 3 Posts
  • 107 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle








  • many2one: so in this relationship you will have more than one record in one table which matches to only one record in another table. something like A <-- B. where (<–) is foreign key relationship. so B will have a column which will be mapped to more than one record of A.

    no, the other way around

    When B has a foreign key to A, many B records may relate to one A record. That’s the many2one part.

    The fact that different B records can point to different A records is irrelevant to that.

    one2many: same as many2one but instead now the foreign key constrain will look something like A --> B.

    It’s the same, mirrored. Or mirrored interpretation / representation to be more specific. (No logical change.)

    If you had B --> A for many2one, then the foreign key relationship is still B --> A. But if you want to represent it from A perspective, you can say one2many - even though A does not hold the foreign keys.

    In relational database schemata, using foreign keys on a column means the definition order is always one to one, and only through querying for the shared id will you identify the many.

    many2many: this one is interesting because this relationship doesn’t make use of foreign key directly. to have this relationship between A and B you have to make a third database something like AB_rel. AB_rel will hold values of primary key of A and also primary key of B. so that way we can map those two using AB_rel table.

    Notably, we still make use of foreign keys. But because one record does not necessarily have only one FK value we don’t store it in a column but have to save it in a separate table.

    This association table AB_rel will then hold the foreign keys to both sides.








  • For a desktop app I would go with none of those.

    If cross platform is the goal, the more important question, and independent of the programming language, is which GUI framework you will use.

    Your best bet, at least if you are looking for a stable GUI framework, the best candidate may be C++ and Qt. But that’s a hassle in its own right - both C++ and Qt.

    TypeScript will have some solutions for you, with web rendering as a desktop app. Golang will have Qt bindings or other more experimental/not thoroughly established+popular GUI frameworks.

    My personal favorite ecosystem is .NET. It has an official cross-platform UI project MAUI, but without an official Linux target. Community extensions probably exist. Personally, I dislike the way the UI is declared and bound though (XAML).

    My current interest, which I have not explored or validate yet, is using .NET but then host a web or Blazor app in it with Webview2. .NET supports cross-boundary programming, crossing web+managed/native development, and crossing web(HTML+JS)+managed.

    Most of the time GUI and the framework technology is a hassle. Your question is too broad and unspecific, so there’s not a good answer.

    If it’s not a “serious” project that you depend on [for your livelihood], pick and start with whatever [looks good or interesting] and go from there. If it is a “serious project” do a bit more GUI framework exploration and assessment, and pick and commit to something. If it’s a big commitment or risk, do prototyping with your candidates for verification and assessment - beyond the most simple examples, and for your specific usage.



  • https://nobaraproject.org/

    The Nobara Project, to put it simply, is a modified version of Fedora Linux with user-friendly fixes added to it. Fedora is a very good workstation OS, however, anything involving any kind of 3rd party or proprietary packages is usually absent from a fresh install. A typical point and click user can often struggle with how to get a lot of things working beyond the basic browser and office documents that come with the OS without having to take extra time to search documentation. Some of the important things that are missing from Fedora, especially with regards to gaming include WINE dependencies, obs-studio, 3rd party codec packages such as those for gstreamer, 3rd party drivers such as NVIDIA drivers, and even small package fixes here and there.