We need to ensure each title length (characters) between 35 and

The discrepancy you are seeing between the ACM Digital Library and the IEEE Xplore database is a common hurdle in Systematic Literature Reviews. It feels jarring, especially when you expect two major repositories in the same field to behave like mirror images. The reality is that these platforms are built on different indexing architectures, utilize distinct metadata standards, and—perhaps most importantly—interpret search queries in ways that are fundamentally incompatible. When you search for "java AND jax+rs" and see a massive gap in results, you are not necessarily seeing a failure of your search strategy, but rather a difference in how these systems handle special characters, stemming, and full-text indexing versus abstract-only indexing.

Understanding the Architecture Gap

IEEE Xplore is notorious for its aggressive full-text indexing. When you run a query, the system often searches the entire body of the paper, including references, footnotes, and even the text within diagrams or tables if they are OCR-processed. If you search for a common term like "java," IEEE pulls in every single document that mentions the language in passing, even if the paper is about something entirely unrelated. ACM, by default, often leans more heavily on metadata, titles, and abstracts. This is why you see thousands of results in IEEE and only a handful in ACM. You are comparing a wide-net trawler to a selective spear-fisher. Consider the experience of Sarah, a third-year Computer Science student working on an SLR regarding RESTful API security. She spent three days frustrated because her IEEE counts were in the tens of thousands, making it impossible to manually screen titles. She realized that IEEE was flagging papers that mentioned "Java" in the bibliography of a paper about network protocols that had nothing to do with her topic. By restricting her IEEE search to "Abstract" or "Title" fields, she brought her results down from 18,000 to a manageable 150. You should check if you are searching the "Full Text & Metadata" field in IEEE, as that is almost certainly the culprit behind your inflated hit count.

The Syntax and Special Character Problem

Different databases handle symbols like the plus sign or the asterisk differently. In many search engines, the plus sign is a reserved character that might be ignored, treated as a space, or interpreted as a specific boolean operator. If the IEEE engine interprets your "jax+rs" as "jax OR rs" or simply strips the plus sign and searches for "jax" and "rs" separately, your hit count will skyrocket. ACM might treat the entire string as a literal phrase or a single keyword token, leading to the significantly lower count you observed. Think about Marcus, a graduate student specializing in software architecture. He was researching OAuth implementations and noticed that his results fluctuated wildly depending on whether he used wildcards like "oauth*". He discovered that IEEE’s search engine was expanding the wildcard to include every possible variation of the string, while ACM was being more conservative. When you encounter these differences, you must normalize your search strings. Try searching for the exact phrase in quotes, and then try searching for the individual components separately. If the results remain drastically different, look for the "Advanced Search" options in both portals to see if you can force them to treat your search terms as "Keywords" rather than "Full Text."

Strategies for Reconciling Your Data

When you are conducting an SLR, your goal is reproducibility. If you cannot explain why you have 18,000 results in one place and 26 in another, your methodology section will be vulnerable to criticism. You need to standardize your search protocol. This often means sacrificing the "full text" search capability of IEEE to match the more limited scope of ACM. By forcing both databases to search only the title, abstract, and author-provided keywords, you create a level playing field. Take the case of Elena and David, two seniors conducting a review on microservices. They were initially overwhelmed by the inconsistent numbers. They decided to create a master search string that functioned in both databases by stripping away special characters and using only standard Boolean operators (AND, OR, NOT). They also agreed to limit their search to the last ten years of publication. By narrowing the scope, they found that the results converged significantly. It is better to have a smaller, high-quality set of results that you can actually defend than a massive, noisy set that you cannot audit.

Quick Self-Assessment for Your Search Strategy

Use this table to audit your current approach and identify why your results are diverging.

Question	What to check
Are you searching full text?	Change your search scope to "Title and Abstract" only.
Are you using special characters?	Remove plus signs or symbols; use standard Boolean operators.
Is the database interpreting your query?	Use double quotes to force exact phrase matching.
Are there hidden filters active?	Check if one database has a default date range or publication type filter.

Managing the Noise in Your SLR

The "noise" in your IEEE results is likely composed of false positives—papers that contain your keywords but are not relevant to your research question. As you move forward, do not be intimidated by the high hit count. It is perfectly acceptable to use a "sampling" approach or to refine your search string until the number of results is manageable for your team. You are not failing the search; you are refining the parameters of your inquiry. Consider the workflow of Jamal, a Master’s student in software engineering. He realized that IEEE was including conference proceedings and short papers that didn't meet his criteria for peer-reviewed journal articles. By applying a filter for "Journal Articles" in the IEEE sidebar, he dropped his results from 18,000 to 400. He then compared these 400 results to his ACM findings and found they were much more comparable. The discrepancy was not just about the search engine; it was about the document type coverage. IEEE includes a vast array of conference papers that ACM might categorize differently or omit entirely.

Refining Your Methodology for Future Scrutiny

When you write up your SLR, you will need to document exactly how you handled these differences. It is not enough to say you searched both; you must explain the limitations of each. If you decide to exclude certain types of documents or restrict your search to specific fields to make the data comparable, document that decision clearly. This shows that you are a rigorous researcher who understands the tools you are using. If you find that your search terms are still producing wildly different results even after normalizing, consider whether the databases themselves have different primary focuses. IEEE is heavily oriented toward electrical engineering and hardware-software integration, while ACM is often more focused on computer science theory and human-computer interaction. If your topic leans toward one of these areas, one database will naturally be more prolific. Acknowledge this in your report. It is a valid observation that the literature on your specific topic is distributed unevenly across these two major repositories.

Resources for Going Deeper

To master these database quirks, look for the following resources or help documentation provided by your university library or the databases themselves.

• Search for "IEEE Xplore Advanced Search Guide" to understand how to use field codes like [Abstract] or [Title].
• Search for "ACM Digital Library Help and FAQ" to learn about their indexing policies and how they handle boolean operators.
• Look for "Systematic Literature Review Methodology in Computer Science" to find templates for documenting search strings and database limitations.
• Consult your university librarian about "Database Normalization for Systematic Reviews" to get professional advice on reconciling disparate search results.

Ultimately, the goal is to be transparent about your process. If you can justify why your search parameters were set the way they were, you have done your job. The numbers themselves are less important than the consistency and the logic you apply to your selection process. Stick to your defined protocol, document every step of your refinement, and do not let the sheer volume of results in one database derail your progress. You are navigating the complexities of academic research, and these challenges are part of the process of becoming a skilled researcher.