Redundant database info in Item Description

[Fred Slota]

The database has a field for Cover Artist... Do we really need 10's of thousands of Item Descriptions of the form "cover by xxxxx"?  I vote "no".

The database separately identifies issue variants as 1, 1/A, 1/B... Do we really need 10's of thousands of Item Descriptions of the form "variant cover" if we already have different cover artists listed?  I vote "maybe, but definitely no if we have a cover scans available.

 

Descriptions with otherwise unencoded information, like "Retailer Excusive" or "1:10", or "Marvel Zombies cover" are useful and should be retained, I think.

[Mark J. Castaneda]

For our Express users who have no cover images, the Item Description info and cover artist info is super helpful.

We're gonna stick with including the lead artist being mentioned in the item description field

[Fred Slota]

Do the Express users not have access to the Cover Artist field?

[Fred Slota]

Fir that matter, what happened to all those using ComicBase 2021 and earlier, since we moved those descriptions out of Notes and into Item Description, a field that the earlier databases don't have?  What happens when updates in the Notes or Item Description are sent in from either version to end users using the other version.

[Michael R. Wagner]

It's generous to accommodate Express version users this way; though since that's important, perhaps you should expand the Express version to provide cover images.  Then, the users of the other versions wouldn't have to carry this data just for the benefit of the Express users.

I usually delete this repetitive data in my copy of the database after I've confirmed it's in the proper field.  With other data in the field and by setting my weekly update appropriately, I avoid the automatic re-population of the cover artist data.

[Mark J. Castaneda]

we have an internal script that moves the old style of description that was in Notes to Item Description. Our Ed. Team will also have a chance to review the data as a last measure to make sure things are in the right format that we use now.

[Mark J. Castaneda]

Express users do have Cover Artist field but not nearly as much cover images that the Archive does; the only get 5,000+.

[Fred Slota]

My point being, if they (and, well, everyone) have the Cover Artist field, then they (everyone) have the information that different variations for a given item have different covers, and thus having generic statements of "Cover by xxx" or "Variant Cover by xxx" are a redundant repetition of data in the database.  

[Fred Slota]

Added question - If I'm remembering correctly, ComicBase didn't always have the Cover Artist field, so for a long time indicating the variant cover artist in the Notes field would have been unique and useful information, but once the Cover Artist field was introduced, retaining these notes is simply database bloat IMHO.

[Adam Sternberg]

Honestly, I find the information in Item Description useful when I'm working on cover artist corrections to match up variant with the artist it goes with.  Sometimes the cover artist information is not correct (against what's printed in the credits in the actual issue) but the info is in the Item Description

[Michael R. Wagner]

That's a good point, but it seems that the way you'd know the cover artist information is not correct (against what's printed in the credits in the actual issue) would be from looking in the actual issue.  This being the case, the redundant data in the Item Description is again that: redundant.  The Cover Artist field has a clear purpose, and was added several years ago to remove the need (up to that time) to put cover art/ink credits in the Item Description.

[Fred Slota]

Curiously tried

I.[ItemDescription] LIKE I.[CoverArtist]

in an attempt to find cover artists names in Item Descriptions.  Initial returns included numerous instances of blank fields in both.  Duh, obviously.  Tried

I.[ItemDescription] LIKE I.[CoverArtist] AND I.[CoverArtist] > ""

and found 4 instances of non-name descriptions in Cover Artist fields.  Corrected and sent.

 

Obviously 

I.[ItemDescription] LIKE "%I.[CoverArtist]%" AND I.[CoverArtist] > ""

finds nothing.  Is there a way to build a "%xxx%" construction where the xxx is a field value and not the literal text string "I.[CoverArtist]"?  I tried

I.[ItemDescription] LIKE '%'+I.[CoverArtist]+'%' AND I.[CoverArtist] > ""

I.[ItemDescription] LIKE '"%'+I.[CoverArtist]+'%"' AND I.[CoverArtist] > ""

And both ran without throwing an error, but found no matching items.

[Steven L. Dasinger]

The short answer is No. You can't use a column name as part of a text string'.

The longer answer is there is a way that should work. Unfortunately it doesn't do exactly what it is supposed to and I can't figure out why without access to the real database with a full set of SQL statements.  

It is getting 'false positives' where the Item Description doesn't have any (apparent) Cover Artists.

But this will get you a list to work with.

This will Find where Cover Artist name (exact and non-exact (i.e. Last name only)) is in Item Description:

INSTR(I.ItemDescription, (SELECT I.CoverArtist From ComicIssues I)) > 0 AND I.ItemDescription <> '' AND I.CoverArtist <> ''

This will Find where Cover Artist name is not an exact match (mostly Last name only) in Item Description (this should be a sub-set of the previous Find (only non-exact matches):

INSTR(I.ItemDescription, (SELECT I.CoverArtist From ComicIssues I)) > 0 AND INSTR(I.ItemDescription, I.CoverArtist) = 0 AND I.ItemDescription <> '' AND I.CoverArtist <> ''

It works by using a sub-select to get a list of Cover Artists:
(SELECT I.CoverArtist From ComicIssues I)

It is using the result of the sub-select as part of the INSTR function.
The INSTR function syntax is INSTR(X,Y) and will looks for any occurrence of Y in X (which is backwards to me to you work with what is supplied). If it finds it, it will return a number (the starting location). If it does not find it, it returns a 0 (or 1 according to the manual but I get unusual results when I use 1).

Theoretically, the sub-select generates a list of all Cover Artists then looks in Item Description to see if it can find any of them. If it does it returns a value greater 0.

(But I can't find 'San Diego', 'SDCC', 'Variant' and a whole host of other values in Cover Artist. And, since they aren't in Cover Artist, they shouldn't be in the sub-select for comparison to Item Description to return those rows without any Cover Artist. It doesn't make any sense and I can't query the actual database to see what is happening)

The second Find is like the first except for the addition of the INSTR comparison not return where exact Cover Artist matches ( = 0 ). This is a little bit of NOT logic. If it Finds an exact match it will return a value > 0 but with a comparison to = 0 they are not returned.

[Doug MedicAR]

While I respect the OP's desire to remove clutter, I'm big on keeping the cover artist in the Item Description.  It's generally the only way to figure out the covers and make sure they get the correct pics. 

[Fred Slota]

1 hour ago, Douglas W. McCratic said:

While I respect the OP's desire to remove clutter, I'm big on keeping the cover artist in the Item Description.  It's generally the only way to figure out the covers and make sure they get the correct pics. 

Except it's not the only way.  It's one of two ways of doing exactly the same thing.  

• Look in what was "Notes", now "Item Description" for an entry like "Cover by John Smith" or "Peter Davis Variant Cover".
• Look in "Cover Artist" for an entry like "John Smith" or "Peter Davis"

Two ways.  Which is one way too many.

Really, this should have been taken care of when the "Cover Artist" field was first created and populated.  You'll notice that when the "Item Description" field was created and populated, the information was removed from the "Notes" field when it was added to the "Item Description" field.  Same thing, only better.

[Doug MedicAR]

More often than not, the "Cover Artist" field is blank or incorrect.  Not sure why, but it seems that the "Notes" field would get all of the information and the "Cover Artist" field was empty. Having the info in the "Item Description" is redundant but redundancy is a good thing. 

[Fred Slota]

2 hours ago, Douglas W. McCratic said:

More often than not, the "Cover Artist" field is blank or incorrect.  Not sure why, but it seems that the "Notes" field would get all of the information and the "Cover Artist" field was empty. Having the info in the "Item Description" is redundant but redundancy is a good thing. 

No.   

No it is not.  Redundancy in a database is bad.  It represents bloat, inconsistency, inefficiency.  Your above description is exactly why this is bad.  If there are two places to enter information in a database, it allows you to enter it only in one, only in the other, or in both, meaning you have to make more complicated searches to find everything, and as stated above you have bloat.

 

A quick search for

• CoverArtist present had over 50,000 instances.
• "cover by" in Notes or ItemDescription where there was nothing in the CoverArtist field found 415 instances.  I'll probably clean those up in the next few days.
• "cover by" in Notes or ItemDescription where there was something in the CoverArtist field found 38,620 instances.  I'll probably not clean those up in the next few days.  That's easily cleaned up by Human Computing with direct and full access to the database.
• There are other forms of noting a cover artist in a free form text description, that are harder or impossible to find.  If I had the ability to run the kind of search I enquired about above, I could give a better accounting.

[Steven L. Dasinger]

Quote

 If I had the ability to run the kind of search I inquired about above...

Can you explain in a sentence what you are looking to find?

FYI, you can't do a Where Item Description is Like Cover Artist and get anything unless the only thing in Item Description is just a Cover Artist name.

That would be looking for the entire contents of Item Description in Cover Artist which would contain things like 'by'.

Actually, LIKE won't really work. You need  INSTR (or something similar) that will look for Cover Artist IN Item Description.

Another problem is that some Item Descriptions only have the Cover Artist's Last name.

I believe the Where clauses I supplied will find what you want. Unfortunately, it is also including other rows that shouldn't be there.

If not, I need a better description of what you are looking for.

[Fred Slota]

I.[Notes] LIKE "%xxx%", but where xxx is I.[CoverArtist]

 

But given the magnitude of the probable overlap, it's really less for me and more for HumanComputing, to be able find and remove the duplicate [Notes] entries in favor of the CoverArtist field.

 

I would suggest they use the find all to detect the linguistic patterns like "cover by Steve Smith" or "Steve Smith variant cover" to craft more targeted finds to modify the database moving the Steve Smiths to CoverArtist and then stripping them out of the Notes field.

[Fred Slota]

Paraphrasing and synthesizing from todays ComicBase TV stream, it sounds like the best-of-both-worlds answer is that the Cover Artist should be in the Cover artist field, while the Item Description field should have enough of a description to identify the cover differences, whether that be "Blue Background", "Foil Cover" or "Variant Cover with Cobra Commander in a dress".  No duplication of information, and a description is a faster means to identify different covers than the artist name.  This might take a while...

[Steven L. Dasinger]

Uh, that isn't quite what Pete said. In his example of a longer description, he included the Cover Artist name. (Without re-watching it, something like 'Blue foil cover by some-artist').

[Doug MedicAR]

2 hours ago, Steven L. Dasinger said:

Uh, that isn't quite what Pete said. In his example of a longer description, he included the Cover Artist name. (Without re-watching it, something like 'Blue foil cover by some-artist').

Just watched it and I came away with the same interpretation.  Something along the lines of "Carlos Pacheco cover with woman holding sword on mountain top" with the idea being to make it as easy as possible to identify which book you're holding. 

[Steven L. Dasinger]

By the way, in the Live-stream when I mentioned being careful because some Item Description data may be deleted, I will give you an example.
For Books, with CB 2021 (prior to Item Description being available), I put information that I called Catalog Number in Notes (I actually stated with Publisher #xxxx (i.e. Ace #F-305)). This was a number printed on the cover of books in the 60's-70's that helps identify various printings.
I moved this to Item Description since that is what it is doing (helping to identify the item) and changed it to a more generic 'Catalog Number: F-305) per discussion with Mark.
I submitted the corrections and the Editors accepted them.
However, since HC always runs a Rebuild List before pushing an Update, the process DELETED all of these corrections from Item Description and the information was lost (well, not completely as I had a backup).
To fix this, I change the information to 'Cover Catalog Number: F-305' and this time it did NOT delete it since 'Cover' was in the string.

[Doug MedicAR]

24 minutes ago, Steven L. Dasinger said:

However, since HC always runs a Rebuild List before pushing an Update, the process DELETED all of these corrections from Item Description and the information was lost (well, not completely as I had a backup).

I shudder to think about how much data I thought was safely entered and then lost before I figured this out. 

[Fred Slota]

I guess my memory retained what I wanted to hear.

 

Printing is a necessary piece of information to identify a book; should that also be repeated in the Notes/ItemDescription?  Annuals are separate items, yet that can safely be kept in its own field.  UPC is also useful to differentiate issues;  I notice no one is advocating repeating this information in Notes/ItemDescription.  

I suspect part of this difference of opinion is that the other fields have been separate since the beginning, while CoverArtist  was only recently introduced.  Earlier, the information was deemed so useful and with no other place to go, it was being entered in the freeform Notes, and now carried over to ItemDescription.  We have thousands on thousands of Cover Artists mentioned in Notes/ItemDescription collected over the years, and people have been using it that way for all those years.  

We've always had cover identification information in the Notes field; that's where we'd go to identify books in the past.  Yet I don't see people asking for the cover description information to be retained in Notes while being copied into ItemDescription.

 

I understand Cover Artist is useful information for issue discrimination.  For those who find it so, why not rearrange the presented field order to place Cover Artist next to Item Description?  I suggest that would make Cover Artist centric folks' lives easier, as it will require less reading and processing of long Notes fields to find this apparently critical piece of information.