Computing desk
< February 13	<< Jan \| February \| Mar >>	Current desk >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

February 14[edit]

What were the 27 Nupedia articles that existed and when were they created?[edit]

I'm making a document about the history of Wikipedia, that's why I'm asking. Mondtaler (talk) 13:45, 14 February 2024 (UTC)[reply]

@Mondtaler: I think that Wikipedia:Nupedia and Wikipedia has most of them listed. According to Nupedia they would have been created between 2000 and 2003, I am not sure if there is a way to be more precise unless the article history here at Wikipedia has the creation dates. RudolfRed (talk) 00:55, 15 February 2024 (UTC)[reply]

I just noticed the info box at Nupedia has links to archived versions. You might be able to get the dates that way. RudolfRed (talk) 00:59, 15 February 2024 (UTC)[reply]

Thanks, I got it now. Mondtaler (talk) 15:45, 16 February 2024 (UTC)[reply]

Temporal optimized database indexes[edit]

Is there a database that implements indexes that allows for temporal importance without indexing dates themselves. I've been wanting to ask this for a while, but I didn't have a good example. I think I have one now. Assume that I have a database of every song-charting system like Billboard 100. I have the chart, date, position, song, and artist for every song on the chart going back as far as I can get data - 1920s maybe. The importance here is that I have a lot of data that required indexing to make finding data quick. Next assumption is that nearly 100% of queries on this database are for artists who have recently released songs. So, for the artist index, I want those at the top of the index tree or heap or stack or whatever is used so they are found faster. I could force it by indexing chartdate and artist and then trying to force a sort on chartdate. That isn't effective though. I don't want every artist to be split into a separate index entry for every date a song charts. What I expect to find is something like the Beatles being near the top of the index because they likely have the most dates with songs charted on all the various music charts around the world. Michael Jackson will be up there as well. But, neither has released a lot of songs recently. Instead, I want Megan Thee Stallion and Dua Lipa to be near the top because they have charted recently. So, the words required to ask this question are difficult because if this example doesn't make it clear, any answer is going to go down a very different path. If it helps, my solution is to partition the data table based on chart date, giving each partition a separate index. Then, querying artists with recent releases will find them in the partition of most recent chart dates. But, if I don't include a date in my query, it will scan the index of all of the partitions to see if the artist appears in any of them. So, this is not really optimal. Also, please simply tell me that this is a stupid request and no database engine has this concept. Then, I can stop trying to find it. 75.136.148.8 (talk) 19:52, 14 February 2024 (UTC)[reply]

You might be going down the path of "premature optimization" - complicating your design by attempting optimizations before you have identified that there is a particular need for that optimization. Looking up an entry in an index has a time complexity of roughly O(log N), where N is the size of the number of entries, so the difference between a lookup into an index of the complete dataset and an index of a subset is not all that great. And for your example, is Michael Jackson really considered "recent" on a 100 year scale? His Thriller album came out over 40 years ago. -- Tom N talk/contrib 23:03, 14 February 2024 (UTC)[reply]

Maybe use Michael Jackson's Structured Programming? Martin of Sheffield (talk) 23:42, 14 February 2024 (UTC)[reply]