design - Pros and cons of making database IDs consistent and "readable" -

question

is rule of thumb database ids "meaningless?" conversely, there significant benefits having ids structured in way can recognized @ glance? pros , cons?

background

i had debate coworkers consistency of ids in our database. have data-driven application leverages spring ever have change code. means, if there's problem, data change solution.

my argument making ids consistent , readable, save ourselves significant time , headaches, long term. once ids set, don't have change , if done right, future changes won't difficult. coworkers position ids should never matter. encoding information id violates db design policies , keeping them orderly requires work that, "we don't have time for." can't find online support either position. i'm turning gurus here @ sa!

example

imagine simplified list of database records representing food in grocery store, first set represents data has meaning encoded in ids, while second not:

---

id's meaning:

type 1 fruit 2 veggie  product 101 apple 102 banana 103 orange 201 lettuce 202 onion 203 carrot  location 41 aisle 4 top shelf 42 aisle 4 bottom shelf 51 aisle 5 top shelf 52 aisle 5 bottom shelf  productlocation 10141 apple on aisle 4 top shelf 10241 banana on aisle 4 top shelf //just reading ids, it's easy recongnize these both fruit on aisle 4 

id's without meaning:

type 1 fruit 2 veggie  product 1 apple 2 banana 3 orange 4 lettuce 5 onion 6 carrot  location 1 aisle 4 top shelf 2 aisle 4 bottom shelf 3 aisle 5 top shelf 4 aisle 5 bottom shelf  productlocation 1 apple on aisle 4 top shelf 2 banana on aisle 4 top shelf //given ids, it's harder see these both fruit on aisle 4 

---

summary

what pros , cons of keeping ids readable , consistent? approach prefer , why? there accepted industry best-practice?

-------- edit ( helpful background info comments, below ): --------

in our tables, primary key id field containing unique integer. @ first, integer arbitrary. on time, of these ids naturally took on meaning among developers/testers. during recent refactor, developers took time make ids easier recognize. made everyone's job 100x easier. people (who don't use data/code) vehemently disagreed theoretical reasons. in practice, not 1 of objections holding true. moreover, developers using data agree it's easier maintain.

i'm looking (but haven't seen) defensible argument against using recognizable ids in data-centric environment.

there several problems using database ids encode information row. if want carrots have "id" of 203, should add product_id column (for example) , put information there instead. why?

1. by customizing ids, have add domain-specific code manages ids , can't rely on database features auto-incrementing or uuids.
2. if ever have change classification, mess table relations, browser bookmarks, search engine results, etc.
3. it's not common practice -- when put application- or domain-specific data id field, assumed many meaningless information, when isn't. need data dictionary (and have ensure people read data dictionary) note fact valuable information.

the required purpose of id uniquely identify row within table. if can provide lookup performance, that's bonus, , if can compactly stored, that's bonus. shouldn't contain information entity in row identifies, other unique identifier of entity.