home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
General Forums
News and Announcements
Music Section gets some TLC
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="jameson_uk" data-source="post: 729007" data-attributes="member: 11220"><p>Unlikely to be any changes as the really messy code that has built up over the years depends on it and I really don't fancy trying to rewrite the music view handler from scratch.</p><p></p><p>That said the database is kind of like the that out of necessity The main issue is that you can have multiple values stored in artist/album artist/composer/genres.... tables. This multi-value / single field thing does not really agree with relational theory <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> </p><p></p><p>Not sure what changes you would want to see? The Tracks table contains all your tracks and most of the info about those tracks. Multi-artist fields are stored in their own tables as unique values. This is meant to make it easier to get say an A-Z listing of artists because we need to store multiple values in one field in the tracks tables you have [code]| artist a | artist b |[/code] which makes that sort of query pretty difficult</p></blockquote><p></p>
[QUOTE="jameson_uk, post: 729007, member: 11220"] Unlikely to be any changes as the really messy code that has built up over the years depends on it and I really don't fancy trying to rewrite the music view handler from scratch. That said the database is kind of like the that out of necessity The main issue is that you can have multiple values stored in artist/album artist/composer/genres.... tables. This multi-value / single field thing does not really agree with relational theory ;) Not sure what changes you would want to see? The Tracks table contains all your tracks and most of the info about those tracks. Multi-artist fields are stored in their own tables as unique values. This is meant to make it easier to get say an A-Z listing of artists because we need to store multiple values in one field in the tracks tables you have [code]| artist a | artist b |[/code] which makes that sort of query pretty difficult [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
General Forums
News and Announcements
Music Section gets some TLC
Contact us
RSS
Top
Bottom